1225750 - garbage or previous tab drawn when image isn't decoded on tab switch

Status: RESOLVED DUPLICATE of bug 1260324

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

Description

[Timothy Nikkel (:tnikkel)]

Load http://www.wcwraces.com/ in a tab. Make another tab the foreground tab long enough for the images in the first tab to get discarded. Switch to the first tab. Garbage, or the contents of the previous tab will be drawn on the right side of the page for a second or so. This is reproducible for me in two different profiles.

(I've seen things like this before, but this is the first time I've had a reproducible testcase.)

Comment 2

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

[Tracking Requested - why for this release]: Regression

Comment 3

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

I see the exact same behavior as in bug 1256211. I'm going to mark this issue as RESOLVED DUPLICATE to bug 1256211, because that bug already has a regression window and more details about hot to reproduce it. If I'm wrong, please feel free to reopen this issue.

Comment 4

[Timothy Nikkel (:tnikkel)]

Bug 1256211 is a worsening of the behaviour of this bug. The regression window for bug 1256211 is well after this bug was filed.

Comment 5

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Recent regression, tracking for 48. 
Andrei, can your team help test to see if this affects 47?

Comment 6

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Timothy can you take this bug or suggest an owner for it? Looks like no one has worked on it since it was filed last year.

Comment 7

[Timothy Nikkel (:tnikkel)]

I actually got some time relatively recently to push on this in bug 1260324.

Also, it affects 47.

Comment 8

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

Timothy, assigning to you based on comment 7, let me know if we should find somebody else.

Comment 9

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

Still possible this will make it in time for 47, Timothy is looking at it.

Comment 10

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

At this point, and given the complexity, I don't see us wanting to uplift.

Comment 11

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Adding tracking for 50, looks like we don't have a fix yet for this regression from 47.

Comment 12

[avada]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #11)
> Adding tracking for 50, looks like we don't have a fix yet for this
> regression from 47.

47? It way precedes 47...
It's present from at least 45 beta/stable. I filed the duplicate of this for 45 and this bug was filed four months before that.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Andre, can we see if bug 1260324 did indeed help this issue on trunk?

Comment 15

[avada]

Attachment: On top: captured right after switching to top. Bottom: normal appearance

(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> Andre, can we see if bug 1260324 did indeed help this issue on trunk?

For what it's worth I still see something. Although it's a lot less noticeable, because the pages are apparently rendered much faster. I seem to betting the images being painted black as before.

I managed to get a frame via screencasting where something shows. I'll attach it.

(I use a user style via stylish for the backgrounds.)

Comment 16

[Paul Silaghi, QA [:pauly]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> Andre, can we see if bug 1260324 did indeed help this issue on trunk?
Can't confirm that, since I wasn't able to reproduce the initial issue on Nightlies before the fix: 2015-11-18, 2016-04-04.
Instead, I'm still reproducing bug 1256211, before and after the fix (51.0a1 (2016-09-14)).

Comment 17

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

Andrew, can you reproduce?

Comment 18

[Timothy Nikkel (:tnikkel)]

(In reply to Paul Silaghi, QA [:pauly] from comment #16)
> (In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> > Andre, can we see if bug 1260324 did indeed help this issue on trunk?
> Can't confirm that, since I wasn't able to reproduce the initial issue on
> Nightlies before the fix: 2015-11-18, 2016-04-04.
> Instead, I'm still reproducing bug 1256211, before and after the fix (51.0a1
> (2016-09-14)).

What exactly are you reproducing from bug 1256211? Flashing black and white background like in the youtube video in the first comment? Or just a white background?

I ask because just showing white is a different problem (kicking off too many decodes of the background image at many different sizes and they all compete and so take forever to complete). Whereas the black and white issue should hopefully be fixed.

Comment 19

[Timothy Nikkel (:tnikkel)]

(In reply to avada from comment #15)
> Created attachment 8790655 [details]
> On top: captured right after switching to top. Bottom: normal appearance
> 
> (In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> > Andre, can we see if bug 1260324 did indeed help this issue on trunk?
> 
> For what it's worth I still see something. Although it's a lot less
> noticeable, because the pages are apparently rendered much faster. I seem to
> betting the images being painted black as before.
> 
> I managed to get a frame via screencasting where something shows. I'll
> attach it.
> 
> (I use a user style via stylish for the backgrounds.)

What are the steps you are using to reproduce? Including stylish, the style you add, and the page you reproduce on.

Comment 20

[Timothy Nikkel (:tnikkel)]

Also, as the reporter of this bug I can confirm that this bug is fixed for me. But I'd like some more info from people who still see this to see if there are other problems.

Comment 21

[Paul Silaghi, QA [:pauly]]

(In reply to Timothy Nikkel (:tnikkel) from comment #18)
> What exactly are you reproducing from bug 1256211? Flashing black and white
> background like in the youtube video in the first comment? Or just a white
> background?
Just the white background, and then it seems the image is properly displayed after 5-10 sec.
So, I guess the black & white issue is fixed.
52.0a1 (2016-09-28), Win 7 x64

Comment 22

[avada]

(In reply to Timothy Nikkel (:tnikkel) from comment #19)
> What are the steps you are using to reproduce? Including stylish, the style
> you add, and the page you reproduce on.

Hi!
I have stylish on the beta channel, so 2.0.1 b1 at the moment. Here's the style: https://userstyles.org/styles/85853/wikipedia-classy-gray-currently-in-works
Any wikipedia page serves.
Other then that, I just set image.mem.surfacecache.min_expiration_ms to 1000 and wait a bit, maybe something like 10 seconds. It "helps" for noticeability if firefox has ben running for a few hours so as such is slower, as does loading a few pages in the background.

Comment 23

[Timothy Nikkel (:tnikkel)]

(In reply to avada from comment #22)
> (In reply to Timothy Nikkel (:tnikkel) from comment #19)
> > What are the steps you are using to reproduce? Including stylish, the style
> > you add, and the page you reproduce on.
> 
> Hi!
> I have stylish on the beta channel, so 2.0.1 b1 at the moment. Here's the
> style:
> https://userstyles.org/styles/85853/wikipedia-classy-gray-currently-in-works
> Any wikipedia page serves.
> Other then that, I just set image.mem.surfacecache.min_expiration_ms to 1000
> and wait a bit, maybe something like 10 seconds. It "helps" for
> noticeability if firefox has ben running for a few hours so as such is
> slower, as does loading a few pages in the background.

I tried and failed to reproduce this. What I suspect is happening based on the screenshots is your Firefox is using a graphics backend that does partial screen updates, and a few parts of the screen get updated and use the (perhaps partially) decoded image because it is available, but the invalidation for the full decode completion of the image hasn't been processed yet (so the whole page isn't repainted). So when each pixel of the page is drawn it is drawing the correct thing (background color if image isn't available, image if it is available) just that we only redraw parts of the page and we get a mix. This is definitely a bug, but it is different from this bug as filed (where we draw incorrect pixels). Please file a new bug for that.

I think we can call this bug fixed.

Comment 24

[avada]

(In reply to Timothy Nikkel (:tnikkel) from comment #23)
> from this bug as filed (where we draw incorrect pixels). Please file a new
> bug for that.

I think you should file that bug, because I don't really understand what it's about.

Comment 25

[Andrew Overholt [:overholt]]

I'm noting the fixed releases from bug 1260324.

Comment 26

[Timothy Nikkel (:tnikkel)]

(In reply to avada from comment #24)
> (In reply to Timothy Nikkel (:tnikkel) from comment #23)
> > from this bug as filed (where we draw incorrect pixels). Please file a new
> > bug for that.
> 
> I think you should file that bug, because I don't really understand what
> it's about.

There's no point in me filing a bug that I can't reproduce. For such a bug to make any progress we'd need help from you to understand what is going on.