Open Bug 1233359 Opened 8 years ago Updated 2 years ago

Glitches after opening images in facebook

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

12 Branch
defect

Tracking

()

Tracking Status
platform-rel --- +
firefox42 --- wontfix
firefox43 --- wontfix
firefox44 --- wontfix
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- fix-optional
firefox50 --- fix-optional
firefox51 --- fix-optional

People

(Reporter: bmaris, Unassigned)

References

Details

(Keywords: regression, top50, Whiteboard: [platform-rel-Facebook])

Affected builds:
- Latest Nightly 46.0a1
- Latest Aurora 45.0a2
- Firefox 43.0.1 RC

Affected OS's:
- Mac OS X 10.9.4
- Ubuntu 14.04 32-bit
- Windows 7 64-bit
- Windows 10 32-bit

STR:
1. Start Firefox
2. Visit https://www.facebook.com/
3. Login and click some images

Expected results: No glitches, visual artifacts present.

Actual results: After clicking the image, there can be seen some glitches.

Notes:
- This is not a recent regression, it reproduces back to Firefox 40 RC as well.
- Chrome does not have this issue.
Even if it goes back to 40, maybe finding a regression window will help out.
A link to a specific image also would help. I'm not sure what to look for here but didn't notice problems when clicking on images.
I'm not seeing any obvious issues either on Win10 or Ubuntu 15.10. Can we get a screenshot of the issue so we better understand what to look for?
Flags: needinfo?(bogdan.maris)
Keywords: top50
I meant to post a screencast but I forgot about that. Here it is: https://db.tt/a5QjhKYT. It can be seen better if the file is downloaded on the machine and then played.

Here is a regression range as well (could not go further with inbound bisection due to the age of the builds):

Last good nightly: 2012-01-04
First bad Nightly: 2012-01-05

Last good revision: 200a8d1fb452 (2012-01-04)
First bad revision: b0e65467c4c8 (2012-01-05)

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=200a8d1fb452&tochange=b0e65467c4c8

There are a few image related bugs and some layout related so I'm not quite sure which could be the culprit here.
Flags: needinfo?(bogdan.maris)
Wow, that's subtle. There's some decode on draw fixes in that range. Seems like a good place to start looking.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #5)
> Wow, that's subtle.

So subtle I couldn't see it. :)

Taking a guess: could the problem be described as drawing the low quality scaled image, and then slightly later replacing it with the high quality scaled image?
(In reply to Timothy Nikkel (:tnikkel) from comment #6)
> (In reply to Ryan VanderMeulen [:RyanVM] from comment #5)
> > Wow, that's subtle.
> 
> So subtle I couldn't see it. :)
> 
> Taking a guess: could the problem be described as drawing the low quality
> scaled image, and then slightly later replacing it with the high quality
> scaled image?

Yep, I think you are correct. 
I just tried again on Ubuntu 14.04 64bit, and there the delay is very noticeable, over 1 second. And I can see with my naked eye that when I click an image, a low quality is displayed, then black image for 1 second, then high quality image. I tried and capture that on a recording but it can't actually be seen (the quality switch).
Jet, can you help find an assignee?
Flags: needinfo?(bugs)
Can we please re-test? The symptoms in comment 7 smell like bug 1225934. However, the regression window in comment 4 almost certainly points to bug 695859, which wouldn't account for such symptoms.
Flags: needinfo?(bugs) → needinfo?(bogdan.maris)
This smells like the sort of thing bug 1130802 was intended to fix. That landed Feb 10, 2015, though, so obviously if it *is* the same type of problem, that patch didn't fix it. (Or we reintroduced it at some point.)

I'll take the bug, but I could *really* use a testcase that does not require logging into Facebook. Bogdan, can you reproduce this on any other site? (Maybe imgur.com?) Or with a local file?
Assignee: nobody → seth
(In reply to Seth Fowler [:seth] [:s2h] from comment #10)
> This smells like the sort of thing bug 1130802 was intended to fix. That
> landed Feb 10, 2015, though, so obviously if it *is* the same type of
> problem, that patch didn't fix it. (Or we reintroduced it at some point.)
> 
> I'll take the bug, but I could *really* use a testcase that does not require
> logging into Facebook. Bogdan, can you reproduce this on any other site?
> (Maybe imgur.com?) Or with a local file?

I reproduced the bug on 45.0.1 (build1), 46.0b4 (build2), 47.0a2 (2016-03-23), 48.0a1 (2016-03-22) and also on 47.0a1 (2016-02-09) using Windows 10 x64, Mac 10.11 Beta and Ubuntu 12.04 (x86). I discovered that the issue is also reproducible for google search images, when choosing Images > Search Tools > Size > Large. I have to mention that I haven`t been able to reproduce it with a locale file.
Flags: needinfo?(bugs)
(In reply to Iulia Cristescu, QA [:IuliaC] from comment #11)
> I discovered that the
> issue is also reproducible for google search images, when choosing Images >
> Search Tools > Size > Large.

That's great news! Should make this much easier to solve.

> I have to mention that I haven`t been able to
> reproduce it with a locale file.

Yeah, if it's a timing problem (which it almost certainly is) then I'm not surprised. A local file probably loads too fast to show the issue.
So I'm planning to circle around to this soon, but if someone else wants to jump in here before then I just want to summarize the places I'd start looking to diagnose this problem. I've tried and cannot reproduce on OS X, but if others can that's great. It sounds like using a diagnostic tool that slows down the network may help, since some timing is probably involved here.

I'd check the following two potential causes first:

- Take a look at which invalidation regions we're getting for the image, and make sure that everything appears sane. The relevant code here would be in nsImageFrame::OnFrameUpdate() and the code it calls, such as InvalidateSelf().

- Make sure that when drawing the image, we're using the already-decoded version of the surface until the new size is completely decoded. ImageSurfaceCache::LookupBestMatch() should enforce this, but there may be bugs, especially if the image is getting layerized, so you may want to look into what's happening in RasterImage::GetImageContainer() and the related methods as well.

A bug in one of those two areas is almost certainly the issue.
Whiteboard: [platform-rel-Facebook]
platform-rel: --- → ?
Version: Trunk → 12 Branch
platform-rel: ? → +
Rank: 92
Assignee: seth.bugzilla → nobody
Product: Core → Core Graveyard
Product: Core Graveyard → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.