User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124pre) Gecko/20100928 Ubuntu/10.04 (lucid) Firefox/3.6.11pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100930 Firefox-4.0/4.0b7pre Firefox 4 beta Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100930 Firefox-4.0/4.0b7pre An animated GIF will stop if the web page is reloaded. I can reproduce this under the following conditions: 1) Firefox 4 beta Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100930 Firefox-4.0/4.0b7pre 2) The animated gif is in a web page. 3) The HTML web page is reloaded using F5 (or clicking on the reload button next to the address bar). The GIF *will* restart under the following conditions: 1) Drag the web page onto the browser. 2) Reload the web page by moving the cursor next to the URL in the address bar and pressing the "enter" key. I get the same results whether I load the page by dragging the web page file onto the browser, or if I load the web page from a web server. I don't have any problems with Firefox 3.6, so this seems to be new to Firefox 4. If I simply load the animated GIF in the web browser directly (i.e. not part of a web page) the problem does not occur even if the GIF is reloaded. It must be part of the web page for this problem to occur. I discovered this problem when testing a web application I am working on. I'm using an animated GIF as a "spinner" while the page is waiting for a server response. In that case, when the animation is stopped I have to close the browser completely and re-open it. If I navigate away from the page and return to it, the animation is stopped and won't restart unless the browser is closed and re-opened. I originally posted this as a reply to bug 595492, but was informed by Boris Zbarsky that this is not the same, and was asked to file it as a new bug. I am posting a sample GIF (this was taken from the 595492 bug, but other GIFs I have tested give the same result) and a sample web page as test cases. Reproducible: Always Steps to Reproduce: 1. Load a web page containing an animated GIF. 2. Refresh the page using F5 or the reload button (next to the address bar). Actual Results: The animated GIF does not run. Expected Results: The animated GIF should run.
Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20101001 Firefox/4.0b7pre Confirmed on win XP. Related to bug 595142? (which should go in bta 7 IMHO)
This sounds like a regression from some of Alon's or Bobby's changes....
Alon, do you have time to look at this?
(In reply to comment #6) > Alon, do you have time to look at this? Yes, as soon as I can I'll check this out. I am hoping my patch for the other related issue will fix it.
Other patch does not fix this. Regression window should help us start to figure out what caused this.
I get this regression range : Last good nightly: 2010-09-07 First bad nightly: 2010-09-08 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cf0088ff07 f2&tochange=36f5cf6b2d42 BUT i didn't check this manually ! I used a regression script that had a off-by-one error the last time
Push log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1633b8d8a184&tochange=4bb022d84a31 Candidate: Bug 359608 - Animated GIFs are animated even when user navigates to another page
7 years ago
This also happens when opening the image in another tab (after having it open in the first) - it won't animate in the second one. This doesn't happen with local images (file:///), only remote ones. It is related to the behavior of caching - we find the image in the cache, but we create another RasterImage anyhow, since it is decided that revalidation is required (in imgLoader.cpp). It is not clear to me what the proper behavior is. The source says // Note, however, that this doesn't guarantee the behaviour we want (one // URL maps to the same image on a page) if we load the same image in a // different tab (see bug 528003), because its load id will get re-set, and // that'll cause us to validate over the network. I think we should clearly define what the proper behavior should be (bug 528003), and then that should make it clear what needs to be done in this bug.
Returning false in ShouldRevalidateEntry removes this bug (and also the case of opening the same image in another tab). I'm not sure though what the downsides are - when exactly is revalidation needed?
We need to revalidate if our cache entry is expired or we've been told to always revalidate (basically, when ShouldRevalidateEntry returns true). Always returning false from that means we never check over the network, and thus never use imgCacheValidator. This makes me suspect that fixing bug 594771 might have a side effect of fixing this bug too.
Created attachment 501426 [details] [diff] [review] patch The problem was that in imgRequestProxy::ChangeOwner, we restored the animation consumers before calling RemoveProxy from the old request. That nulled out the consumers, so they were lost. The patch moves the restoration to after the RemoveProxy call.
Verified fixed (GIF restarts) with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre, reproduced with the old build Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110124 Firefox/4.0b10pre.