animated gif stalls when page opened locally

VERIFIED FIXED in Firefox 36, Firefox OS v2.2

Status

()

Core
Layout: Images
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Steve Williams, Assigned: mattwoodrow)

Tracking

({regression})

36 Branch
mozilla38
x86_64
Windows 8.1
regression
Points:
---
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox35 unaffected, firefox36+ verified, firefox37+ verified, firefox38+ verified, b2g-v2.2 fixed, b2g-master fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150125221831

Steps to reproduce:

Unzip this minimal reproducable test case to local drive on windows :

http://advance-software.com/misc/local_anim_gif_stall_bug.zip

open the html file using ff36b9 *locally* from that drive.


Actual results:

page displays showing first frame of the animated gif


Expected results:

the gif should play its animation (it does if you hit refresh or load the page/gif over http.
(Reporter)

Updated

3 years ago
Component: Untriaged → Layout: Images
OS: Linux → Windows 8.1
Product: Firefox → Core
Keywords: regressionwindow-wanted

Comment 1

3 years ago
[Tracking Requested - why for this release]:
status-firefox35: --- → unaffected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
tracking-firefox36: --- → ?
tracking-firefox37: --- → ?
tracking-firefox38: --- → ?

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

3 years ago
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=02d3440cd34b&tochange=c786bdac4406
Flags: needinfo?(tnikkel)
Keywords: regressionwindow-wanted → regression

Comment 3

3 years ago
via local build
Last good: 1d1810ba0ebf
First bad: a958224850fb

Regressed by: a958224850fb	Seth Fowler — Bug 1097432 (Part 1) - Remove imgStatusTracker::Send* methods and clean up.
No longer blocks: 1097405, 1097431, 1098108
Timothy, are you going to take that? 
Matt, can you help on this?

FYI, we are going to make a beta 10 before the RC but the go to build is today.
Flags: needinfo?(matt.woodrow)
tracking-firefox36: ? → +
tracking-firefox37: ? → +
tracking-firefox38: ? → +
Today is a holiday where I live and I've already made plans so I can't look at this until tomorrow.
(In reply to Alice0775 White from comment #3)
> via local build
> Last good: 1d1810ba0ebf
> First bad: a958224850fb
> 
> Regressed by: a958224850fb	Seth Fowler — Bug 1097432 (Part 1) - Remove
> imgStatusTracker::Send* methods and clean up.

Thank you Alice. This is very helpful.
(Assignee)

Updated

3 years ago
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 7

3 years ago
Created attachment 8565137 [details] [diff] [review]
image-fix

The regressing changeset is http://hg.mozilla.org/mozilla-central/rev/a958224850fb

The loop within imgStatusTracker::OnDataAvailable *doesn't* check NotificationsDeferred, unlike all the others within the file.

Switching to using the macro added this check, and broke this.

This patch just expands the macro out again, and removes the check for NotificationsDeferred.
Attachment #8565137 - Flags: review+
(Assignee)

Comment 8

3 years ago
 https://hg.mozilla.org/integration/mozilla-inbound/rev/2b28ac1903c5
(Assignee)

Comment 9

3 years ago
Comment on attachment 8565137 [details] [diff] [review]
image-fix

Approval Request Comment
[Feature/regressing bug #]: Bug 1097432
[User impact if declined]: Animated gifs loaded locally don't animate.
[Describe test coverage new/current, TreeHerder]: Tested manually.
[Risks and why]: Very low risk, just reverts the one functional change from a patch that was meant to be a cleanup.
[String/UUID change made/needed]: None.
Flags: needinfo?(tnikkel)
Attachment #8565137 - Flags: approval-mozilla-beta?
Attachment #8565137 - Flags: approval-mozilla-aurora?
Comment on attachment 8565137 [details] [diff] [review]
image-fix

Guys, you are really impressive! Thanks
Attachment #8565137 - Flags: approval-mozilla-beta?
Attachment #8565137 - Flags: approval-mozilla-beta+
Attachment #8565137 - Flags: approval-mozilla-aurora?
Attachment #8565137 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 11

3 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/997fae1e1f88
https://hg.mozilla.org/releases/mozilla-beta/rev/1e50a728d642
(Assignee)

Updated

3 years ago
status-firefox36: affected → fixed
status-firefox37: affected → fixed
Flags: qe-verify+
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/997fae1e1f88
status-b2g-v2.2: --- → fixed
status-b2g-master: --- → fixed
I've verified this fix today on Windows 7 x64, using the latest Firefox 37 Aurora (BuildID=20150217004007) which should have this fix (as indicated by its pushlog). 

I used scenario from comment 0, and while most of the time everything worked fine, on several occasions the GIF did NOT animate (stuck either on the first or the last frame). I could not quite figure out exactly what causes the GIF to not animate when it happens. It seems to reproduce more often if I repeatedly drag the html file in Firefox:
1. Open Aurora with clean profile and drag & drop the local HTML from comment 0 to open it.
2. Drag & drop the HTML in Aurora for the second time.
3. Drag & drop the HTML in Aurora for the third time.

In the video from http://www.screencast.com/t/ExCLMK7vqRF you can see how:
- step 1 - GIF animates as expected
- step 2 - GIF stuck on first frame
- step 3 - GIF stuck on last frame

As mentioned, this is a scenario where this happens more often, but I've experienced the GIF stuck on first or last frame a few times even when opening the file for the first time with a clean profile.

Also note that this also happens in Aurora sometimes when you load http://imgur.com/gallery/rZ4FQoK, so I believe this may actually be a separate issue from this one. If anyone could review this issue and confirm that it's separate from this bug, and not on file, then I can go ahead and file it separately... just let me know. Otherwise it may need fixing ASAP since this fix was already uplifted to Beta 36 and last Beta will happen very soon.

Comment 14

3 years ago
I can confirm reproduced the problem comment#13 on the following Aurora37.0a2(as indicated by its pushlog)
https://hg.mozilla.org/releases/mozilla-aurora/rev/997fae1e1f88
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150217004007
It's my understanding (based on comments Seth left in bugs) that he was prioritizing getting his regression fixes uplifted to beta, so that there are several important fixes that could and should be uplifted to aurora but just haven't yet due to lack of time (and using the limited time available to get fixes to beta).

So I would say to focus on testing beta and nightly. If neither of those are affected by the bug then it's likely one of the patches that will get uplifted to aurora eventually will fix it.
https://hg.mozilla.org/mozilla-central/rev/2b28ac1903c5
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox38: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
(In reply to Timothy Nikkel (:tn) from comment #15)
> So I would say to focus on testing beta and nightly. If neither of those are
> affected by the bug then it's likely one of the patches that will get
> uplifted to aurora eventually will fix it.

Thank you Timothy! I think you are right about this as I cannot reproduce the issues on Nightly 38 and Beta 36. I didn't get the chance to fully test this today, but from what I managed to do, things look good so far. Tomorrow we'll actually start looking into all the future uplifts to Aurora 37 (that you were mentioning), so I'll return with the final test results then.
I continued testing today on Firefox 36 Beta 10 (BuildID=20150217132925) and the latest Firefox 38 Nightly (BuildID=20150218030228) on Windows 7 x64, but despite trying various scenarios I did not encounter any issues playing the local page with the GIF, or the imgur page with the GIF (confirmed ok also on Mac and Ubuntu).

I'm marking this as verified for 38 and 36, and will check 37 after the additional uplifts.
status-firefox36: fixed → verified
status-firefox38: fixed → verified
Verified as fixed on Firefox 37 beta 6 under Win 7 64-bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5.
Status: RESOLVED → VERIFIED
status-firefox37: fixed → verified
You need to log in before you can comment on or make changes to this bug.