Closed Bug 1101759 Opened 5 years ago Closed 5 years ago

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


(Core :: ImageLib, defect)

Not set



Tracking Status
firefox35 --- unaffected
firefox36 + fixed


(Reporter: jonathan, Assigned: seth)



(Keywords: regression)


(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:


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)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141118113724
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141118120727

Suspect: Bug 1079653
Blocks: 1079653
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

1) Open the following gifs in new background tabs.
2) Rapidly cntl-click the gifs.
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 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):
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 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
Flags: needinfo?(seth)
Attachment #8525884 - Flags: review?(tnikkel) → review+
Thanks for the super quick review! Pushed:
(In reply to Chris Peterson (:cpeterson) from comment #11)
> FWIW, I only see this bug with e10s enabled.
> 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
Disregard what I wrote, downloaded the wrong branch...
Works in
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Duplicate of this bug: 1103002
Using nightly 2014-11-22, I am no longer seeing this. Thanks!
You need to log in before you can comment on or make changes to this bug.