User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20151208100201 Steps to reproduce: I have a website: http://www.h-team.eu/ On the header part there are many gifs stapled all in the same place. With a little bit of javascript, the latest is changed to "display:none" and the next is "display:inline" The update time is 6 seconds. My GIF is actually bigger than my 1000px * 200px Actual results: After loading the site the first time, the second gif is displayed only in a part and not the full size. Expected results: With Firefox 42 there was no problem. The gif showed everytime full, even after updating to the next image.

[Tracking Requested - why for this release]: break web layout I can reproduce on Nightly46.0a1. https://hg.mozilla.org/mozilla-central/rev/f143af51f6e35932927b8ccac2509facbbe7b539 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20151217030207 Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=54d0fc9946067a995cc49326fd3861303cd1f105&tochange=c035b63e1b816877cfdfcedfc7b530e1a0ad4308 Regressed by: Bug 1194059

So there is a chance that this bug will be patched to Firefox 44? :) Because every other browser (Internet Explorer, Opera, Chrome) do render the gifs correctly.

Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/animated-gifs-are-drawn-partially-if-hidden-at-first/

I just added the right size of the GIFs to my site. So there is no need for downscaling anymore. Without downscaling there are no bugs. The are just displayed full, even if they are hidden like in my case. So maybe the bug is only if the GIFs are hidden and downscaled. :)

Recent regression, and it would be good to fix, but I'm not sure we need to track this.

Given that this was a wontfix for FF43 and does not sounds critical enough, marking it as wontfix for FF44 as well.

Jet, can you help get some movement here?

It looks like we get incorrect size info for these GIFs on first decode.

So I have two questions here: (1) I can reproduce flashing during the transition from one GIF to the next, but not a partial display of the GIF - it sounds to me like you're saying that for you, we only draw a small part of the bigger GIF. Is that true, or is the flashing what you're talking about? (2) Does setting "image.downscale-during-decode.enabled" to false in about:config and then shift-reloading the page fix the problem?

(In reply to Jet Villegas (:jet) from comment #9) > Created attachment 8730619 [details] > Image properties on first load (0px x 0px) > > It looks like we get incorrect size info for these GIFs on first decode. Hmm. I kinda suspect that's just a bug in the image properties code, but I'm not sure. Checking in about:memory, the SurfaceCache has the correct values for the size of these GIFs.

(In reply to Seth Fowler [:seth] [:s2h] from comment #10) > So I have two questions here: > > (1) I can reproduce flashing during the transition from one GIF to the next, > but not a partial display of the GIF - it sounds to me like you're saying > that for you, we only draw a small part of the bigger GIF. Is that true, or > is the flashing what you're talking about? > > (2) Does setting "image.downscale-during-decode.enabled" to false in > about:config and then shift-reloading the page fix the problem? By the way, if you can it'd be good to test this on Nightly, as we've recently fixed a number of problems that feel kinda similar to me, and it's possible that we "accidentally" fixed this bug already.

No response from the bug reporter in over a month. Alice, could you try testing this on the latest Nightly to see if it still reproduces?

I can still reproduce the problem with attachment 8699496 [details] on Latest Nightly48.0a1[1]. [1] https://hg.mozilla.org/mozilla-central/rev/0891f0fa044cba28024849803e170ed7700e01e0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160422030223

Thanks for testing, Alice. Milan, it looks like this is still valid. Who can work on this?

I debugged this, I found three different problems, I have patches for two, need to polish my patch for the third.

Posted patches to bug 1270997, bug 1270999, bug 1271002 to fix this.

I don't think we need any more info from the reporter, we can reproduce this.

Timothy, once we have all three patches, and this is fixed - is it something that looks reasonable for an aurora uplift?

Two of the three parts should be fine for uplift, the third (that we are still waiting on review for) is more involved, I'd like at minimum some bake time before uplift.

Milan, do you have an idea on what we should do here? Thanks

(In reply to Sylvestre Ledru [:sylvestre] from comment #21) > Milan, do you have an idea on what we should do here? Thanks Yes, he does. Bug 1270999 needs to be fixed.