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

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.

Thanks for the super quick review! Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/faaa05e4e03d

FWIW, I only see this bug with e10s enabled. http://yahoo.tumblr.com/post/103069386424/yahoo-and-mozilla-partner-to-bring-yahoo-search-to

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

Using nightly 2014-11-22, I am no longer seeing this. Thanks!