1027741 - Find out why this Reddit user has had a glitchy front-end since Firefox 29.

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

Attachment: Glitchy browser UI

A user on Reddit reported some pretty awful glitches in their browser after the 29 upgrade. Specifically, it looks like sections of the browser UI are simply not being drawn.

See the attachment for an example.

That's pretty awful. We've eliminated HWA, add-ons, and profile-specific prefs as potential culprits. The screenshot is from a brand-new profile.

What might be happening here?

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Graphics information from the user (pre HWA disabling):

Adapter Description AMD Radeon HD 5800 Series
Adapter Drivers aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM 1024
ClearType Parameters Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100
Device ID 0x6899
Direct2D Enabled true
DirectWrite Enabled true (6.2.9200.16571)
Driver Date 12-6-2013
Driver Version 13.251.0.0
GPU #2 Active false
GPU Accelerated Windows 1/1 Direct3D 10
Vendor ID 0x1002
WebGL Renderer Google Inc. -- ANGLE (AMD Radeon HD 5800 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote false
AzureCanvasBackend direct2d
AzureContentBackend direct2d
AzureFallbackCanvasBackend cairo
AzureSkiaAccelerated 0

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Hey BenWa, any other ideas for this user to try for debugging?

Comment 3

[Benoit Girard (:BenWa)]

The best way would be to get a display list. We can then know if we're wanting to draw the bars there or not. This would tell us if it's a rendering problem or not.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

(In reply to Benoit Girard (:BenWa) from comment #3)
> The best way would be to get a display list. We can then know if we're
> wanting to draw the bars there or not. This would tell us if it's a
> rendering problem or not.

So I should get Douglas a build with --enable-dump-painting, get him to flip layout.display-list.dump to true, and enable OMTC, right?

And then use the Gecko Profiler to capture the DisplayList? Or just capture it from the console?

Comment 5

[Benoit Girard (:BenWa)]

(In reply to Mike Conley (:mconley) from comment #4)
> (In reply to Benoit Girard (:BenWa) from comment #3)
> > The best way would be to get a display list. We can then know if we're
> > wanting to draw the bars there or not. This would tell us if it's a
> > rendering problem or not.
> 
> So I should get Douglas a build with --enable-dump-painting, get him to flip
> layout.display-list.dump to true, and enable OMTC, right?

They don't need OMTC. But avoid running e10s since you're going to have a display list for each process.

> 
> And then use the Gecko Profiler to capture the DisplayList? Or just capture
> it from the console?

If you go the profiler route then you should make sure it hasn't regressed. It's a new feature that hasn't received much testing yet.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Try push with --enable-dump-painting here: https://tbpl.mozilla.org/?tree=Try&rev=8cb541ed3136


Ok, Douglas - so I've kicked off a build of a specially instrumented version of Firefox that I'll want you to run. I'll give you instructions on how to run it (it's going to be different from the way you normally run it), and that's going to create a file which I'll want you to attach to this bug.

Once the instrumented build has finished, I'll give you the link and more instructions. Until then, sit tight.

Comment 7

[Benoit Girard (:BenWa)]

Actually I forget that debug build also have display list dumping.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

(In reply to Benoit Girard (:BenWa) from comment #7)
> Actually I forget that debug build also have display list dumping.

Meh, too late. It's OK, the build is done. Plus, I've had difficulties in the past running debug builds without some system prep - having to get things like MSVC100D.DLL and whatnot. I'd rather not have Douglas go through that.

Hey Douglas, here's your download link:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8cb541ed3136/try-win32/firefox-33.0a1.en-US.win32.zip

Step 1:

Unzip that somewhere close to the root of your main drive (which I'll assume is C:). Somewhere like C:/firefox-test.

So the following file should exist:

C:/firefox-test/firefox/firefox.exe


Step 2:

Close all other copies of Firefox, and then run this Firefox you just downloaded.


Step 3:

Go to about:config and right click to create a new Boolean value. Name it layout.display-list.dump and set the value to True. Close the browser.


Step 4:

Hit WindowsButton-R to open up the "Run" dialog. Type

cmd

and press enter to drop to the command console.


Step 5:

Type:

cd C:\firefox-test\firefox

to switch into the directory that you unzipped the file. Swap out firefox-test for whatever you ended up calling it.


Step 6:

Type:

firefox.exe -no-remote > "C:\firefox-test\displaylist.log" 2>&1

and press Enter. Firefox should open. 


Step 7:

Do whatever you need to do to reproduce the problem.


Step 8:

Close Firefox, and then re-open it or open your old Firefox (or a different browser). Come to this bug, and click on "Add an attachment" (it's kinda hidden away, but it's at the bottom of the attachment list where I posted your screenshot).

Step 9:

In the page that comes up, click "Browse" in the file input, and select the displaylist.log file that should have been created in C:\firefox-test\.

You can skip the rest of the fields. Just click "Submit" at the bottom.


It's a lot of steps, I know. Let me know if you hit any roadblocks on any of these.

Comment 9

[Douglas]

Attachment: displaylist.rar

Comment 10

[Timothy Nikkel (:tnikkel)]

What was the text on the tab(s) that wasn't showing up in this display list dump?

Comment 11

[Douglas]

(In reply to Timothy Nikkel (:tn) from comment #10)
> What was the text on the tab(s) that wasn't showing up in this display list
> dump?

They were the names of images. The glitch only happens with image tabs, usually only if they've been open for a while without being switched to. Mousing over them makes them reappear, or waiting several seconds.
So to start I opened a bunch of image tabs, and I got the glitch to happen a couple times during the dump. The first time I switched to the last tab and the entire row of tabs disappeared. I moused over the invisible tabs and they reappeared.
Then I switched around some more and the first few tabs disappeared. I waited until they reappeared, then I closed the window and ended the log dump.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Is the attached displaylist log showing anything interesting?

Comment 13

[Benoit Girard (:BenWa)]

It's too hard to read. I would need a single dump of a buggy frame + a corresponding screenshot.

The other thing which might be better would be to run a regression window with mozregression if this broke in FF29.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

(In reply to Benoit Girard (:BenWa) from comment #13)
> It's too hard to read. I would need a single dump of a buggy frame + a
> corresponding screenshot.
> 

Is there an easy way for Douglas to generate that?

> The other thing which might be better would be to run a regression window
> with mozregression if this broke in FF29.

Hey Douglas - do you have the time to help us find the revision that introduced this bug? That'd really help us narrow down what might be happening here.

If so, the tool you'll need is called "mozregression" - it'll download Nightly snapshots of 29 as it was being developed which you can test. Each time you test one, you mark it "good" or "bad", and eventually, you bisect down to the Nightly that first introduced it.

If you have the time, the instructions for getting and using the tool are here: http://mozilla.github.io/mozregression/

Follow the Windows installation instructions, and once you've got it installed, at the mozilla-build prompt, type:

mozregression --good=2013-11-17 --bits=32

If all goes well, a copy of Nightly will be downloaded and run. Test it out, and then go back to the prompt and tell it if it was a good or bad build. It will keep downloading and running Nightly's until it's found the changeset range, and then it will spit out a link to the changeset range.

According to my estimate, it'll take approximately 7-9 downloads and tests to drill down to the Nightly that started this.

If you could then comment in this bug with the changeset range, that'd really help.

Can you do that, Douglas? Let me know if you need any help.

Comment 15

[Douglas]

I did what you asked, but I encountered the bug in the very first nightly it downloaded: http://i.imgur.com/BIThKb0.png

Should I try dumping another log?

Comment 16

[Mike Conley (:mconley) (:⚙️)]

(In reply to Douglas from comment #15)
> I did what you asked, but I encountered the bug in the very first nightly it
> downloaded: http://i.imgur.com/BIThKb0.png
> 
> Should I try dumping another log?

If you found the bug in the first version that it downloaded, that's fine - tell mozregression "bad", and it'll keep searching.

Basically what's going on is this: we have a date where all of the UI changes for Australis first landed (November 18th, 2013), and we have today's date which has a Nightly that is in a "bad" state.

mozregression will first choose a date X in between November 18th and now, and show you that build. If it's bad (and it looks like it was), it's going to choose a date Y in between November 18th and X, and so on.

If, however, we find that the bug was present in the November 18th build, we might have to move the regression window start point back a bit, and start searching earlier (but we will be able to tell mozregression that November 18th is a "bad" date, so it's not wasted effort).

So, to sum, what you see is not unexpected. Tell mozregression "bad", and keep moving.

Comment 17

[Douglas]

http://i.imgur.com/f7NFWXi.png
What do I do from here?

Comment 18

[Mike Conley (:mconley) (:⚙️)]

(In reply to Douglas from comment #17)
> http://i.imgur.com/f7NFWXi.png
> What do I do from here?

Hm, ok - so it looks like it's possible that the glitch was introduced before any of the Australis stuff merged.

It's asking if you want to start building Firefox and bisect individual changesets - I think we can skip that bit for now. Go ahead and say "n" for no.

So we now know that the glitch was introduced on or before November 18th.

We have to find a build where the glitch did not exist.

mozregression comes with a sister script called "moznightly" that allows you to download a Nightly for a given date. We need to find a Nightly where this bug does not exist for you.

You're going to have to start casting back earlier and earlier to find a date that doesn't have the bug. Then we'll bisect between that date and November 18th.

So try this:

moznightly --date=2013-09-01 --bits=32

That'll grab the Sept 1, 2013 Nightly and let you try it. If the bug is not there, great - we've found a good date, and we can bisect via:

mozregression --good=2013-09-01 --bad=2013-11-18 --bits=32

If the September 1st Nightly does have the bug, keep going further. Maybe go by months, so try:

moznightly --date=2013-08-01 --bits=32

and keep going back until you find a date that doesn't have the bug. You shouldn't have to go too far if Firefox 28 didn't have the bug for you.

Comment 19

[Douglas]

Okay, here is the order I tested and the results I got.
good = could not reproduce glitch
bad = was able to reproduce glitch
* = dates which I got inconsistent results, probably due to error on my part

2013-09-01 bad
2013-08-01 bad
2013-07-01 bad
*2013-06-01 bad*
*2013-05-01 bad*
2013-04-01 good
2013-04-10 good
2013-04-20 good
2013-04-25 good
*2013-04-30 good*
*2013-05-01 good*
*2013-06-01 good*
2013-09-01 bad
2013-04-01 good
*2013-05-01 bad*
2013-04-01 good
*2013-05-01 bad*
*2013-04-30 bad*
2013-04-01 good
2013-04-20 good
2013-04-25 good
*2013-04-30 bad*
2013-04-29 bad
2013-04-28 bad
2013-04-27 good
2013-04-28 bad
2013-04-26 good
2013-04-27 good
2013-04-28 bad
2013-04-27 good
2013-04-28 bad

So right now, I THINK the glitch first appears on the 2013-04-28 nightly, but I'm not 100% sure.

Comment 20

[Mike Conley (:mconley) (:⚙️)]

Assuming April 28 was the first bad Nightly, here are the changesets between April 27 and April 28:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e45f1b9521f&tochange=9d8977cbbfc6

Comment 21

[Mike Conley (:mconley) (:⚙️)]

Hey BenWa, any potential culprits / explanations in that changeset range?

Comment 22

[Douglas]

Attachment: testscreens.rar

Comment 23

[Mike Conley (:mconley) (:⚙️)]

BenWa - anything at all we can do for this user?

Comment 24

[Mike Conley (:mconley) (:⚙️)]

So I was just talking to BenWa about this, and we still don't have enough information to figure out what's going on here.

And we've not had any luck reproducing it either, which is making this particularly hard.

Douglas - what we're going to try to do is get you to bisect this for us further, down to the changeset that introduced the problem.

Since there are about 50 changesets in there, assuming this push is the one that introduces the bug, it should only take 5 or 6 bisections to find the culprit.

A remote bisection is gonna suck, and might take a few days, but at least we'll (hopefully) end up with the regressing changeset, and that's a big clue.

I've kicked off some builds for you to try. When they're ready, I'll give you links.

Comment 25

[Mike Conley (:mconley) (:⚙️)]

Grrr... these builds failed:

https://tbpl.mozilla.org/?tree=Try&rev=c9bbb09c57c2
https://tbpl.mozilla.org/?tree=Try&rev=9c8e90902334


Douglas, I think I'm going to have to resort to building this on my own machine and sending you the executable. You're just gonna have to trust that I'm not doing anything evil. :/ Sorry about that.

Comment 26

[Mike Conley (:mconley) (:⚙️)]

Ok, here are the builds.

Douglas - 

You'll need to decompress each, and run the Firefox executable inside.

Can you confirm that the "bad" build is indeed "bad" (has your bug), and the "good" build is indeed "good" (does not have your bug)?


BAD: http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.9d8977cbbfc6.zip


GOOD: http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.e01f456f8a47.zip

Comment 27

[Douglas]

replicated bug with the bad build. did not encounter bug with the good build. (sorry I took so long to test)

Comment 28

[Mike Conley (:mconley) (:⚙️)]

That's OK - I've got the next step ready. Here's a build from right between these two builds.

Does this have the bug or not?

http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.04235d548347.zip

Comment 29

[Douglas]

yes that one has the bug

Comment 30

[Mike Conley (:mconley) (:⚙️)]

Thanks Douglas.

It's a long weekend, so I'll have a new build for you to try on Tuesday. I'll needinfo you when it's ready.

Comment 31

[Mike Conley (:mconley) (:⚙️)]

Ok, here's the next build to try, Douglas:

http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.54106990fcd8.zip

Comment 32

[Douglas]

that build has the bug too

Comment 33

[Douglas]

also after I ran that build you just posted I kept getting an "invalid URL" error to almost every website, even in regular firefox, and it didn't go away until after I did a system restore

Comment 34

[Mike Conley (:mconley) (:⚙️)]

(In reply to Douglas from comment #33)
> also after I ran that build you just posted I kept getting an "invalid URL"
> error to almost every website, even in regular firefox, and it didn't go
> away until after I did a system restore

System restore? Geez... sorry if the build caused that, though I'm not sure how that could have happened... :/

I have another build for you to try: http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.adef5d952d72.zip

We're narrowing down - only 3 or so builds to test.

Comment 35

[Douglas]

That build has the bug.

Also I might have been wrong about the build causing my internet trouble, I probably just overreacted. I switched to google's DNS and the problem stopped

Comment 36

[Mike Conley (:mconley) (:⚙️)]

Ok, and how about this one?: http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.40dafc376794.zip

Glad you solved your connection issue.

Comment 37

[Douglas]

That one doesn't have the bug

Comment 38

[Mike Conley (:mconley) (:⚙️)]

Ok, another build coming up.

For those following along at home, we've bisected down to the following changes:

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0e45f1b9521f&tochange=adef5d952d72

My money is on bug 853564 or bug 862970.

Comment 39

[Mike Conley (:mconley) (:⚙️)]

Ok Douglas, how about this one: http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.fe381d10084f.zip

Good or bad?

Comment 40

[Douglas]

that one's bad.

Comment 41

[Mike Conley (:mconley) (:⚙️)]

Ok, last one - good or bad?:

http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.45d40d37b1df.zip

Comment 42

[Douglas]

that one is bad

Comment 43

[Mike Conley (:mconley) (:⚙️)]

We have a winner - bug 853564.

jrmuizel or BenWa... does that narrow this problem down in a useful way? What else can we do to figure out what Douglas is hitting?

Comment 44

[Timothy Nikkel (:tnikkel)]

I made two try builds to try to figure out what is going on here. One is a (more or less) backout of http://hg.mozilla.org/integration/mozilla-inbound/rev/45d40d37b1df (the code has changed a bit since then) to see if backing it out from the current tree fixes the issue. One moves acquiring the decoding mutex further up in case we where hitting some kind of threading problem on shared variables.

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-91692c8f2098/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-d0d88f6689bd/try-win32/firefox-34.0a1.en-US.win32.zip

Comment 45

[Douglas]

First build has the bug.

Second build does not have the bug.

Comment 46

[Mike Conley (:mconley) (:⚙️)]

So I believe that'd be this patch that reverted the bug:

https://hg.mozilla.org/try/rev/076efa6212c5

That appears to be the backout of 45d40d37b1df.

Thanks for helping us confirm, tn! Is there anything else Douglas can provide that we can use to figure out what's going on here?

Comment 47

[Timothy Nikkel (:tnikkel)]

I created a build based on a hunch of what the problem might be.

Can you please test this build? Thanks

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-03afd4780230/try-win32/firefox-34.0a1.en-US.win32.zip

Comment 48

[Douglas]

that build still has the bug

Comment 49

[Mike Conley (:mconley) (:⚙️)]

Any other hunches or ideas, tn?

Comment 50

[Timothy Nikkel (:tnikkel)]

Okay, I got a bunch of builds with a bunch of wild guesses.

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-e7b629669b9d/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-39781e3896c4/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-9edff1c5965b/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-de4127972251/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-12cb151731e1/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-24a597ebcf70/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-84553bfbe59b/try-win32/firefox-34.0a1.en-US.win32.zip

Comment 51

[Douglas]

1: GOOD
2: bad
3: bad
4: GOOD
5: bad
6: GOOD
7: GOOD

Comment 52

[Timothy Nikkel (:tnikkel)]

Thank you. From that I'm pretty sure it is the FinishedSomeDecoding call when we have pending work done that is notifying and invalidating and this RequestDecodeCore call is happening during painting, so that messes things up. The regressing changeset moved this FinishedSomeDecoding call before the |if (mDecoder && !mDecoder->IsSizeDecode() && mBytesDecoded)| early exit. So the likely course of events is a RequestDecode call during painting that either doesn't finish before returning or isn't asked to do any decoding, and then during the same paint another RequestDecode call is made (so that we haven't made it back to the event loop to process the work done by the decode) and we notify for the pending work done.

I think the switching of the order of the mBytesDecoded if and the FinishedSomeDecoding call was the core of the bugfix, so it prevents image flashing from happening so we can't just simply change the order to fix this.

The other sadness here is that having the mBytesDecoded check before we acquire the lock was the only thing preventing the main thread from blocking (waiting for the lock) while a decoding thread was decoding (and held the lock), thereby removing the main benefit of off main thread decoding.

So to fix this we'll need to figure out who is making a RequestDecode call of the synchronous notify kind during painting.

Comment 53

[Timothy Nikkel (:tnikkel)]

More builds. Thanks for your extreme patience :)

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8d3378587653/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-9d065edee3f2/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-94d5b48af3ff/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-76ae0762fcc6/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f40014202c52/try-win32/firefox-34.0a1.en-US.win32.zip

Comment 54

[Douglas]

1: GOOD
2: bad
3: GOOD
4: bad
5: GOOD

Comment 55

[Timothy Nikkel (:tnikkel)]

(In reply to Timothy Nikkel (:tn) from comment #52)
> The other sadness here is that having the mBytesDecoded check before we
> acquire the lock was the only thing preventing the main thread from blocking
> (waiting for the lock) while a decoding thread was decoding (and held the
> lock), thereby removing the main benefit of off main thread decoding.

I filled bug 1051531 for this.

Comment 56

[Timothy Nikkel (:tnikkel)]

Thanks again. More builds, making progress now.

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-6ade0386415a/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-0d04e4463927/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a09f3a1a0dea/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b69420f4aeaf/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-eaab568bc23b/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-dbdce029aec8/try-win32/firefox-34.0a1.en-US.win32.zip

Comment 57

[Douglas]

1: bad
2: bad
3: bad
4: GOOD
5: GOOD
6: GOOD

Comment 58

[Timothy Nikkel (:tnikkel)]

So this means it's the decode complete notification that standalone image documents are observing. They add/remove a CSS class to the image which controls the background color (so that in progress images look good as well as complete images that have transparency). So we are indeed invalidating during paint.

Comment 59

[Timothy Nikkel (:tnikkel)]

Hopefully this is the last build. It's not yet there at the time I post this comment because I just pushed, but it should be there in about an hour.

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-ce59016af246/try-win32/firefox-34.0a1.en-US.win32.zip

Comment 60

[Douglas]

GOOD! Did not encounter bug using that build.

Comment 61

[Timothy Nikkel (:tnikkel)]

Attachment: do the decode complete work on a script runner

comment 58 describes what's happening. This isn't the greatest patch.

Comment 62

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8470536 [details] [diff] [review]
do the decode complete work on a script runner

The patch is fine.
(!nsContentUtils::IsChildOfSameType(this) checks are really odd, but
that is just a regression from  Bug 841547, and not about this bug.)

Comment 63

[Timothy Nikkel (:tnikkel)]

I think the IsChildOfSameType calls are because we give a different presentation to toplevel image documents than we do to image documents inside an iframe in a content page. Toplevel images get a dark background, images in an iframe get white, so we don't need to add a white background just behind the image in case it is transparent as the whole document has a white background.

Comment 64

[Olli Pettay [:smaug][[e-mail]]]

Sure, but exposing classes differently to the web is rather odd.
Anyhow, not about this bug.

Comment 65

[Timothy Nikkel (:tnikkel)]

https://tbpl.mozilla.org/?tree=Try&rev=5e284b25e288

Comment 66

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/878ede98eacb

Comment 67

[Timothy Nikkel (:tnikkel)]

Thanks Douglas for your help and patience, it would have been impossible to fix this bug without your help.

Comment 68

[Mike Conley (:mconley) (:⚙️)]

Curious bystander here - why was Douglas experiencing this? What about his environment made him run into this, and is it possible to estimate how widespread this problem likely was?

Comment 69

[Nigel Babu [:nigelb]]

https://hg.mozilla.org/mozilla-central/rev/878ede98eacb

Comment 70

[Timothy Nikkel (:tnikkel)]

I don't have a great explanation for that and I was wondering it myself. The nature of the bug is that the timing of several things on different threads needs to work out in a certain fashion. So I would expect this bug to manifest as a very occasional problem for everyone, rather than a very easy to reproduce problem for one person.

For this bug to appear we need to have a top level image document, if the user watches the image download we most likely won't see the bug. So we need an image to be fully downloaded, but not decoded. Then we need a decode of the image to be triggered, and then a paint to be triggered before it finishes, but by the time the paint gets around to actually drawing the image the decode has finished.

Comment 71

[Mike Conley (:mconley) (:⚙️)]

Hm, ok, thanks tn. Pretty mysterious and troubling.

Douglas reported having this bug on release, so I have to assume it's a problem all the way up to Beta.

[Tracking Requested - why for this release]:

Requesting tracking for 32 and 33 because this is apparently an issue on release, at least for Douglas. Unsure how widespread it is. Just wanted to get this on release driver radar.

Comment 72

[Sylvestre Ledru [:Sylvestre]]

Timothy, can we get an uplift request for aurora & beta? Thanks

Tracking because it breaks Firefox UI and it could affect a bunch of users.

Comment 73

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8470536 [details] [diff] [review]
do the decode complete work on a script runner

Approval Request Comment
[Feature/regressing bug #]: bug 853564
[User impact if declined]: if a user is unlucky enough to trigger this their browser window including the chrome would get messed up (see attached screenshots)
[Describe test coverage new/current, TBPL]: nothing that I know of, it's very hard to reproduce this, nevermind with an automated test
[Risks and why]: the only potential risk here that I can see is if a user is viewing a top level image and the image is transparent they _might_ be more likely to see a jarring flash when the background behind the image goes from black to white (note this flash already exists when a user is watching an image progressively render while downloading it)
[String/UUID change made/needed]: none

Comment 74

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8470536 [details] [diff] [review]
do the decode complete work on a script runner

I am taking it for 33. Lawrence will decide for 32.

Comment 75

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3dace7559a93

Comment 76

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8470536 [details] [diff] [review]
do the decode complete work on a script runner

While this is a pretty old bug (dates back to Firefox 22/23), the result is pretty bad and the code change looks to be mostly a refactoring. I think it's worth trying to take in beta7. If there is noticeable fallout, which I don't expect as there hasn't been on m-c, we should be prepared to backout in time for beta9.

Comment 77

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d4e47ec57f06

Comment 78

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

So this needs specific hardware for testing? 

Juan is this a setup you all may have in the QA lab in MV?

Douglas, you rock! Thank you for all your testing.  Would you like to verify this fix in the Aurora release? :)

Comment 79

[juan becerra [:juanb]]

Unfortunately none of the machines we have in the lab match the specs in comment #1. We are going to have to ask Douglas, one more time, to help us out with verifying this fix once it is available in beta builds (tomorrow).

Comment 80

[gmonster]

Looks like the same issue I've been getting since the same version of Firefox. Open a bunch of images in the background then switch back to them later and the chrome is glitched (every single time). I'm on beta, so I can also see if this fixes it when I get it I suppose.

Comment 81

[gmonster]

(In reply to gmonster from comment #80)
> Looks like the same issue I've been getting since the same version of
> Firefox. Open a bunch of images in the background then switch back to them
> later and the chrome is glitched (every single time). I'm on beta, so I can
> also see if this fixes it when I get it I suppose.

Looks like it's fixed on my machine now.

Comment 82

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Marking as Verified on Beta 32, based on comment 81.

Comment 83

[Catalin Varga [QA][:VarCat]]

Hi gmonster, I've noticed that this issue was reproducible on your machine.
None of our machines are matching the specs needed to test this bug.
If you could check if this issue is reproducible on the latest FF 33 beta this would be greatly appreciated. Here is the link to FF 33.0b2 beta candidate https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/33.0b2-candidates/build1/ 
Thanks

Comment 84

[gmonster]

(In reply to Catalin Varga [QA][:VarCat] from comment #83)
> Hi gmonster, I've noticed that this issue was reproducible on your machine.
> None of our machines are matching the specs needed to test this bug.
> If you could check if this issue is reproducible on the latest FF 33 beta
> this would be greatly appreciated. Here is the link to FF 33.0b2 beta
> candidate
> https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/33.0b2-candidates/
> build1/ 
> Thanks

No problem. Appears to work just fine for me.

Comment 85

[Catalin Varga [QA][:VarCat]]

Thanks again gmnoster.
Marking the bug as verified on:

FF 33.0b2
buildID=20140908190852

per above comment.