Closed Bug 1101759 Opened 10 years ago Closed 10 years ago

Bugzilla's "mozchomp" animated gif is broken/corrupted in Nightly

Categories

(Core :: Graphics: ImageLib, defect)

x86_64
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla36
Tracking Status
firefox35 --- unaffected
firefox36 + fixed

People

(Reporter: jonathan, Assigned: seth)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached image shot.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141119030200

Steps to reproduce:

Open https://bugzilla.mozilla.org/extensions/BMO/web/images/mozchomp.gif



Actual results:

Animation stops. See shot.


Expected results:

Was fine in nightly 20141118 and prior.
WFM on OS X...
[Tracking Requested - why for this release]:

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/33425fc431a5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141118113724
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/dff90d1d4b3c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141118120727
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33425fc431a5&tochange=dff90d1d4b3c

Suspect: Bug 1079653
Blocks: 1079653
Status: UNCONFIRMED → NEW
Component: Untriaged → ImageLib
Ever confirmed: true
Flags: needinfo?(seth)
Keywords: regression
OS: Linux → All
Product: Firefox → Core
Summary: Animated gif broken in nightly 20141119 → Bugzilla's "mozchomp" animated gif is broken/corrupted in Nightly
Version: 36 Branch → Trunk
STR posted in http://forums.mozillazine.org/viewtopic.php?p=13885493#p13885493

1) Open the following gifs in new background tabs.
2) Rapidly cntl-click the gifs.
http://i.imgur.com/VWU7iBj.gif
http://i.imgur.com/GBBCtJ0.gif
http://i.imgur.com/yAyYZtH.gif
http://i.imgur.com/2s90aeX.gif
http://i.imgur.com/4VXPAT1.gif
http://i.imgur.com/i1mj5On.gif
3) Wait for the gifs to load in the background.
4) Switch to the gifs, and some of them are broken.
FWIW on the STR in comment 0 and comment 4: I can reproduce this (on Linux) 100% reliably by simply loading https://bugzilla.mozilla.org/extensions/BMO/web/images/mozchomp.gif directly.  (I checked in a fresh profile, too; it reproduces reliably there, too.)  No e10s dependency, either.

I can reproduce this with the GIFs in comment 4, too, but for those ones, I *only* see the bug if I load them in a background tab (via Ctrl-click). (No need to rapidly click, and it happens for every ctrl-click-spawned tab.)  Those ones don't reproduce the bug if I left-click them (to load in foreground tab).

Might be some race condition in play, where e.g. the bug only reproduces if you get all of the image data before decoding starts (and decoding is delayed in background tabs, which is why ctrl-clicking makes it more reproducible). I'm in the Mozilla MV office, so I likely have a fast pipe serving the mozchomp GIF image, which would help explain why that one repro's more reliably. (It also might be smaller)
I've also observed the issue with the animated GIF on this page (sadly):

http://yahoo.tumblr.com/post/103069386424/yahoo-and-mozilla-partner-to-bring-yahoo-search-to
I should note that I can't reproduce this on OS X at all. From what I've seen though, it reproduces 100% of the time with the test case in comment 6 on Linux. I'm testing Windows now.
I can reproduce this (on Windows 8.1) 100% reliably by simply loading https://bugzilla.mozilla.org/extensions/BMO/web/images/mozchomp.gif directly.
The fix turns out to be really simple: during sync decoding, in Decoder::Write we call AllocateFrame() and then immediately flush, but we weren't updating mNeedsToFlushData. It's set to true by AllocateFrame, and we should've been setting it to false after flushing, which is the change this patch makes.
Attachment #8525884 - Flags: review?(tnikkel)
Assignee: nobody → seth
Status: NEW → ASSIGNED
Flags: needinfo?(seth)
Attachment #8525884 - Flags: review?(tnikkel) → review+
Thanks for the super quick review! Pushed:

https://hg.mozilla.org/integration/mozilla-inbound/rev/faaa05e4e03d
(In reply to Chris Peterson (:cpeterson) from comment #11)
> FWIW, I only see this bug with e10s enabled.
> 
> http://yahoo.tumblr.com/post/103069386424/yahoo-and-mozilla-partner-to-bring-
> yahoo-search-to

I could see that affecting it; whether the bug became visible was a matter of timing.
I still can reproduce with the STR of comment 4 in an inbound build which supposedly has the patch of comment 10, like http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1416490326/
Disregard what I wrote, downloaded the wrong branch...
Works in http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1416490326/
https://hg.mozilla.org/mozilla-central/rev/faaa05e4e03d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Using nightly 2014-11-22, I am no longer seeing this. Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: