1233359 - Glitches after opening images in facebook

Status: NEW

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

Description

[Bogdan Maris, Desktop Test Engineering]

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.

Comment 1

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

Even if it goes back to 40, maybe finding a regression window will help out.

Comment 2

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

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.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

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?

Comment 4

[Bogdan Maris, Desktop Test Engineering]

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.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Wow, that's subtle. There's some decode on draw fixes in that range. Seems like a good place to start looking.

Comment 6

[Timothy Nikkel (:tnikkel)]

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

Comment 7

[Bogdan Maris, Desktop Test Engineering]

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

Comment 8

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

Jet, can you help find an assignee?

Comment 9

[Jet Villegas (inactive)]

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.

Comment 10

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

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?

Comment 11

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

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

Comment 12

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

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

Comment 13

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

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.