I'm loading 2 embedded svg-lets in a page. One animated one not. They're loaded in sequence with a setTimeout.
When I load the animated first all goes well, the animation starts as expected and the second static svg is correctly displayed afterwards. When I first load the second, and afterwards the animated one, the animation does not start.
Code is here: jsfiddle switch #svg1, and #svg2 in the javascript.
Upon browser checking I found out this is probably a webkit bug as chrome and safari both show this behavior FF 12 and Opera are well.
Can this be fixed with JS code or should I file a bug with webkit?
== Added
I think the question should be rephrased why the animation does not start after the svg is loaded with a settimeout.
As Jared investigated below it works when the element is present in the DOM and is reordered via dom manipulation into the focus element, Chrome and webkit need a kick with a beginElement() call to the animate element. This still doesn't work out for elements constructed from plain text. As I only do have a mac and I still consider this a hobby project I leave MS IE completely out of the loop.
Well, it took quite a bit longer than I anticipated, but I got it worked out. Basically, the method you were using with the semi-SVG and the regex on the markup, etc., was to say the least not quite the way to get it done.
The answer is to use svg DOM animation methods and attributes, especially to start/stop the animation when you want it to run. Apparently, Firefox was just fine with reinitializing the element and the animation just by manipulating the inner HTML/markup. Chrome (Webkit?), however, actually needs you to programmatically access and control the element. I have not checked in IE, Opera or Safari.
I redid the example, leaving out the arrow altogether, as it is unrelated to the problem. I instead concentrated on creating and testing the animation functionality. The critical points you were missing before were:
var $lasso = $('#lasso'),
animater = $lasso.find('animate')[0],
...
animater.beginElement();
...
animater.endElement();
Here is the demo I made, which is significantly different that what you have in your question:
http://jsfiddle.net/9hBfs/
What I call the "lasso" effect is still there, though.
I would reference the Mozilla Developer Network (MDN) site, as they have a lot of great information and are a highly trusted authority:
https://developer.mozilla.org/en/SVG
https://developer.mozilla.org/en/SVG/Element/animate
http://www.w3.org/TR/SVG11/animate.html#animation-mod
http://www.w3.org/TR/SVG11/animate.html#InterfaceElementTimeControl
http://www.w3.org/TR/SVG11/animate.html#RestartAttribute
Related
We're using the javascript plugin Simple-ajax-uploader to upload files on your web site and it suddenly stopped working today (09/05/2019).
The upload div/button can't be clicked on anymore.
This is happening on our site and even on the official plugin site.
This is only happening on Chrome and only on computers where Chrome has been closed and restarted today.
We found out this article indicating that Chrome Dev tools have just been updated today but our version of Chrome hasn't changed since the restart (76.0.3809.132). However the restart definitely triggered the bug so something happened there. But what?
Same problem here found this morning.
Quick jQuery fix...
$('input[type=file]').css('position','relative');
UPDATE: Issue has been fixed with version 2.6.5 of the plugin. Ignore the below.
Plugin maintainer here. A short term fix is to remove or comment out line 2002:
'position' : 'absolute',
Alternatively: the issue does not appear to be present in Firefox. At any rate, I'll try to have a fix pushed soon.
I've just checked on Chrome and you're right about the button not working. It is a problem with the Stacking Context, unfortunately each browser has its own implementation.
Basically the outer div is preventing the click events from reaching the inner input.
My suggestion would be to use a custom button or to restyle the current one (I've found that if you remove the position property from the outer div it will work again. Consider that many properties can cause stacking context problems: position, transform, opacity, z-index. Try adding/removing/modifying some of them, in the outer div and in the inner input).
Anyway, it is guaranteed to be a style problem and not a JavaScript problem.
Hi I'm following a tutorial in using easelJS for writing browser based games. And the tutorial is going fine but I've noticed some problems whilst playing the animations on chrome.
Chrome runs the animations slower and once played through once the same animation will not play again unless I reload the page.
Running in Firefox it doesn't have any of these problems.
Here's the link: (use inspect element for code)
http://david.blob.core.windows.net/easeljstutorials/easelJSSpritesTutorial03.html
I've heard there are some caching problems in chrome so I thought this might be the problem.
Manually deleting the cache does in fact allow the animation to play again without a page reload, but it still runs slowly (compare it to firefox).
As I want to code for cross browser compatibility is there a supported way in chrome to combat these problems? Such as blocking storing the images in cache or something? (A last resort I hope)
Thanks in advance,
Kyohei
EDIT: It seems the speed of the animation is the same on ie10 so not sure what speed it should be you know.
The reason this will not work after a "reset" is that you are relying on the image load events to kick off the animation. This will work the first time, but the second time, the image is already loaded, and therefore you will never get an onload event from the images (meaning no "startGame()".
Since this is a simple example, maybe the best approach is to create new Images each time. Just move these lines into your init:
function init() {
var imgMonsterARun = new Image();
var imgMonsterAIdle = new Image();
// Other stuff
}
i read an article Fix your Timestep it will help you , just need to convert it to javascript , read it carefully .
UPDATED TO ADD FIDDLE: http://jsfiddle.net/wvUqy/6/
I have a page_action in Chrome that parses the response from an XHR to make a menu of video clips for download. There is a <span class="status"> for each clip that defaults to blank, shows "Pending" when queued, and changes to either "INTERRUPTED" (in red) or "Complete" depending on how the download stops. These behaviors, and updating <span class="status"> with percentage of download complete as it progressed all work fine.
I tried to swap out displaying the percentage string for a <progress> bar instead, but as soon as I introduce that element into the document, I start getting rendering problems ONLY WHEN I'm not using Chrome Dev Tools.
Here's a 2min video of the odd behavior in action:
http://www.youtube.com/watch?v=M50F5ly93MM
The fiddle link at the top will output to console as it periodically (every 5s) changes display property for the <span> and <progress> elements, but they never appear. If you comment out the line subDiv.appendChild('progressBar') and change nothing else, the behavior of the <span class="Status"> is magically fixed.
Everything works as expected when no <progress> elements are in the document; it works as expected if the setInterval var is created within a button's onclick function; it works as expected if you "Inspect Element" the result pane in Dev Tools.
In all cases, it works as expected in Firefox, but I'm trying to build a Chrome extension specifically.
You are most probably running into a manifestation of https://bugs.webkit.org/show_bug.cgi?id=84242 - a bisection gave me http://trac.webkit.org/changeset/83065 which dealt with a major rewrite of the <progress> element implementation. I will link that bug to this question - perhaps the former will get some more attention.
I investigated a progress bar bug recently. I filed the bug to webkit, you may find it relevant: https://bugs.webkit.org/show_bug.cgi?id=100507 .
So there is apparently a hacky way to get around this: http://jsfiddle.net/wvUqy/9/
For reasons I don't quite understand, making a trivial update to the containing <div> (e.g. ChildContainer.style.display = ChildContainer.style.display;) when updating the <progress> and <span> element(s) will correct the rendering behavior.
I've implemented this in my page_action script and it works fine. Would be nice if this bug were resolved in Chrome, but this is a fine interim solution.
I've checked out the other page jump questions here on SO and I haven't found anything that matches, so here we go...
I'm working on building a website that uses CSS3 transitions and a bunch of hash-links as opposed to using jQuery to load/transition different pages/elements (just for fun/to prove that I/CSS can). The problem I'm having is that when I click on one of my links, the scrollbar automagically jumps down about 100px for no apparent reason.
I don't recall it doing this the entire time, so maybe something in my CSS went weird. I also added some <a name> tags at the top to try to pull it back up, but that's not working either. I also tried putting onclick="window.scrollTo(0,0);" in the links as well and that doesn't work either :(
Any ideas/help would be awesome, as it's really annoying/poor usability to have to scroll every time you navigate to the page. You can view the page here.
System Info:
Browser(s): Chrome 16.0.912.75, FireFox 9.0.1, Opera 11.6
OS: Windows 7
I'm not familiar with CSS3 transitions, so I don't fully understand what you're doing. However:
I assume this behavior that you find undesirable has something to do with the browser's native behavior of scrolling an element into view based on the fragment identifier in the URL. I'm not sure if overriding that with <a name> elements would work, but in any case you've incorrectly set the name values by prefixing them with a hash. E.g should be <a name="about"></a> not <a name="#about"></a>.
At least for debugging purposes, I'd try adding a click event listener and calling preventDefault() in it to see if it stops the scrolling.
It would be helpful to state what browser (including OS and version) you're experiencing the issue in.
Notice that it is not just jumping down to a random place, it is jumping down to the element that has the ID of the hash. (Try adding #footer to the end of your url) I do not think you can get around that without using preventDefault in JavaScript.
This innerHTML code wasn't working reliably in IE8:
(but was working in IE6 IE7 FF Opera Chrome Safari)
(by not working reliably I mean I had placed this code within onmouseover handlers on various elements, sometimes it would change the text when mousing over a given element and sometimes it wouldn't - there was no pattern to this - whether it would work or not seemed to be totally random)
document.getElementById("mydiv").innerHTML="some text";
DOM methods (removing and re-adding the div with updated text) weren't helping either.
So I added this immediately after the above code and it fixed it:
document.styleSheets[0].addRule("#mydiv:after", "content: ' ';");
Using conditional comments I identified this 2nd line of code as for IE8 only
I am positive this will save people a lot of time since I have wasted ages on this!
Even Jquery.text() wasn't helping!
I have read elsewhere that the innerHTML will update the DOM but can fail to update screen elements. I believe the CSS rule works because it changes the content of the after pseudo class of #mydiv dynamically and thus requires the content of mydiv to be updated, thus updating the screen (something innerHTML was failing to do).
However if anyone has a better solution I'd love to hear - Thanks
EDITED AS REQUESTED
You can use innerText in place of innerHTML