Open Bug 1309534 Opened 4 years ago Updated 2 years ago
Glitches when zoom in .jpg files from Wikipedia
[Affected versions]: - latest Nightly 52.0a1 (2016-10-11) - latest Aurora 51.0a2 (2016-10-11) - 50.0b6 build1 (20161010144024) - 49.0.1 build3 (20160922113459) [Affected platforms]: - Windows 10 x64 - Mac OS X 10.11.6 - Ubuntu 14.04 x86 [Steps to reproduce]: 1. Launch Firefox 2. Go to https://en.wikipedia.org/wiki/File:Portrait_Gandhi.jpg (or https://en.wikipedia.org/wiki/Mahatma_Gandhi) 3. Zoom in using [CTRL] and [+] keys (or mouse wheel and [+] key) - pay attention to the displayed image [Expected result]: - The zooming process goes smoothly and the image is properly displayed [Actual result]: - Image glitches can be observed usually at 110% and 160% zoom levels (sometimes at 120%) [Regression range]: - Last good revision: 3cc3b1968524248450c465c4ea2ee5596ffa65f2 - First bad revision: 285852de5cd54891d8f3b1ddbff179e4c9c7ca5f - Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3cc3b1968524248450c465c4ea2ee5596ffa65f2&tochange=285852de5cd54891d8f3b1ddbff179e4c9c7ca5f - Possible regressor: bug 1166138 [Additional notes]: - The glitches are mostly reproduced: * when first zooming the image (page containing the image) or after a restart * using mouse wheel and [+] key (when gradually browse the zoom levels)
4 years ago
Too late to fix for 49, marking fix-optional for 50. Sounds like something we should fix, but not urgent.
What do you mean by glitch? What does the glitch look like? Can you get a screen recording? I couldn't see the problem when I tried.
(In reply to Timothy Nikkel (:tnikkel) from comment #2) > What do you mean by glitch? What does the glitch look like? Can you get a > screen recording? I couldn't see the problem when I tried. Here is a screenshot https://drive.google.com/file/d/0B0nYKG6PRiCcMzlpSkZGR3huZGc/view?usp=sharing of the issue. Pay attention at 110% and 160% zoom levels (I used mouse wheel and [CTRL] key). I also have to make a correction for comment 0 - I meant "mouse wheel and [CTRL] key" instead of "mouse wheel and [+] key". Sorry for that!
I'm guessing that is when we decide to use a different source image from the srcset of the image and it isn't decoded yet.
(In reply to Timothy Nikkel (:tnikkel) from comment #4) > I'm guessing that is when we decide to use a different source image from the > srcset of the image and it isn't decoded yet. Good guess. In async decoding mode, glitch seems an inevitable result we can expect. From my test, it's not easy to run into as well. I don't think it's a regression in general. If we won't make it any further, I'll resolve this bug to won't-fix.
Priority: -- → P3
Is it reproducible on google Chrome or other browsers ?
(In reply to Astley Chen [:astley] UTC+8 from comment #6) > Is it reproducible on google Chrome or other browsers ? Probably not. Chrome seems to do all image decoding synchronously.
(In reply to Astley Chen [:astley] UTC+8 from comment #6) > Is it reproducible on google Chrome or other browsers ? Sorry for the late answer! The issue is not reproducible on other browsers, like Google Chrome and Edge.
Also reproduced the issue on 53.0a1 (2016-12-19). Marking the build as affected.
tnikkel, would you think there is a room to improve it given that gecko is doing decode asynchronously ?
We could add logic to show the previous image until the new image is decoded I guess.
4 years ago
platform-rel: --- → ?
4 years ago
platform-rel: ? → +
Comment 10 says there's room to improve this, but I take it we're not planning on fixing this anytime soon?
You need to log in before you can comment on or make changes to this bug.