[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
Status: UNCONFIRMED → NEW
status-firefox42: --- → unaffected
status-firefox43: --- → affected
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox46: --- → affected
status-firefox-esr38: --- → unaffected
tracking-firefox43: --- → ?
tracking-firefox44: --- → ?
tracking-firefox45: --- → ?
tracking-firefox46: --- → ?
Component: Untriaged → ImageLib
Ever confirmed: true
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.
Summary: Gifs don't displayed full. → Animated GIFs are partially drawn if those are hidden at first
Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/animated-gifs-are-drawn-partially-if-hidden-at-first/
Keywords: dev-doc-needed → dev-doc-complete
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.
status-firefox43: affected → wontfix
tracking-firefox43: ? → +
tracking-firefox46: ? → -
Given that this was a wontfix for FF43 and does not sounds critical enough, marking it as wontfix for FF44 as well.
status-firefox44: affected → wontfix
tracking-firefox44: ? → -
Jet, can you help get some movement here?
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.
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.  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
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox-esr45: --- → affected
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.
Assignee: seth → tnikkel
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.
status-firefox45: affected → wontfix
status-firefox46: affected → wontfix
status-firefox47: affected → wontfix
status-firefox49: --- → affected
status-firefox-esr45: affected → wontfix
Timothy, once we have all three patches, and this is fixed - is it something that looks reasonable for an aurora uplift?
2 years ago
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.
2 years ago
status-firefox48: affected → wontfix
status-firefox49: affected → fix-optional
status-firefox50: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.