Animated GIFs do not run when the page is reloaded.

VERIFIED FIXED

Status

()

Core
ImageLib
VERIFIED FIXED
7 years ago
5 years ago

People

(Reporter: mg, Assigned: azakai)

Tracking

(Depends on: 1 bug, {regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [softblocker][fx4-fixed-bugday])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.11pre) 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.
(Reporter)

Comment 1

7 years ago
Created attachment 480724 [details]
Sample web page for test case. A GIF file is also required.
(Reporter)

Comment 2

7 years ago
Created attachment 480725 [details]
GIF file to go with the sample web page.

Comment 3

7 years ago
Created attachment 480744 [details]
testcase
Attachment #480724 - Attachment is obsolete: true

Comment 4

7 years ago
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)
Status: UNCONFIRMED → NEW
Component: General → ImageLib
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → imagelib
Hardware: x86_64 → All
Version: unspecified → Trunk

Updated

7 years ago
blocking2.0: --- → ?
This sounds like a regression from some of Alon's or Bobby's changes....
Keywords: regression
Alon, do you have time to look at this?
Assignee: nobody → azakai
blocking2.0: ? → final+
Keywords: regressionwindow-wanted
(Assignee)

Comment 7

7 years ago
(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.
(Assignee)

Comment 8

7 years ago
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

Comment 10

7 years ago
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
Blocks: 359608
Keywords: regressionwindow-wanted
(Assignee)

Comment 11

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.
Depends on: 528003
(Assignee)

Updated

7 years ago
Blocks: 588975
(Assignee)

Comment 12

7 years ago
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.
Duplicate of this bug: 621330
(Assignee)

Comment 15

7 years ago
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.
Attachment #501426 - Flags: review?(joe)
Whiteboard: [soft blocker]
Whiteboard: [soft blocker] → [softblocker]
Attachment #501426 - Flags: review?(joe) → review+
(Assignee)

Comment 16

7 years ago
http://hg.mozilla.org/mozilla-central/rev/410390378caa
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 17

7 years ago
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.
Whiteboard: [softblocker] → [softblocker][bugday0204]
Whiteboard: [softblocker][bugday0204] → [softblocker][fx4-fixed-bugday]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.