1233403 - Animated GIFs are partially drawn if those are hidden at first

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[github]

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.

Comment 1

[Alice0775 White]

[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

Comment 2

[github]

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.

Comment 3

[Alice0775 White]

Attachment: reduced.zip

Comment 4

[Kohei Yoshino]

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

Comment 5

[github]

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. :)

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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

Comment 8

[Brad Lassey [:blassey] (use needinfo?)]

Jet, can you help get some movement here?

Comment 9

[Jet Villegas (inactive)]

Attachment: Image properties on first load (0px x 0px)

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

Comment 10

[Seth Fowler [:seth] [:s2h]]

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?

Comment 11

[Seth Fowler [:seth] [:s2h]]

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

Comment 12

[Seth Fowler [:seth] [:s2h]]

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

Comment 13

[u279076]

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?

Comment 14

[Alice0775 White]

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

Comment 15

[u279076]

Thanks for testing, Alice.

Milan, it looks like this is still valid. Who can work on this?

Comment 16

[Timothy Nikkel (:tnikkel)]

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

Comment 17

[Timothy Nikkel (:tnikkel)]

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

Comment 18

[Timothy Nikkel (:tnikkel)]

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

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 20

[Timothy Nikkel (:tnikkel)]

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.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

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

Comment 22

[Timothy Nikkel (:tnikkel)]

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