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

VERIFIED FIXED in Firefox 32

Status

()

defect
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: mconley, Assigned: tnikkel)

Tracking

({verifyme})

Trunk
mozilla34
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox31 wontfix, firefox32+ verified, firefox33+ verified, firefox34 verified, firefox-esr31 wontfix)

Details

Attachments

(4 attachments)

Posted image 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?
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
Hey BenWa, any other ideas for this user to try for debugging?
Flags: needinfo?(bgirard)
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.
Flags: needinfo?(bgirard)
(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?
Flags: needinfo?(bgirard)
(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.
Flags: needinfo?(bgirard)
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.
Actually I forget that debug build also have display list dumping.
(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/mconley@mozilla.com-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.
Flags: needinfo?(tohellwithutube)

Comment 9

5 years ago
Posted file displaylist.rar
Flags: needinfo?(tohellwithutube)
Assignee

Comment 10

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

Comment 11

5 years ago
(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.
Is the attached displaylist log showing anything interesting?
Flags: needinfo?(bgirard)
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.
Flags: needinfo?(bgirard)
(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.
Flags: needinfo?(tohellwithutube)

Comment 15

5 years ago
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?
Flags: needinfo?(tohellwithutube)
(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

5 years ago
http://i.imgur.com/f7NFWXi.png
What do I do from here?
(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

5 years ago
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.
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
Hey BenWa, any potential culprits / explanations in that changeset range?
Flags: needinfo?(bgirard)

Comment 22

5 years ago
Posted file testscreens.rar
BenWa - anything at all we can do for this user?
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.
Flags: needinfo?(bgirard)
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.
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
Flags: needinfo?(tohellwithutube)

Comment 27

5 years ago
replicated bug with the bad build. did not encounter bug with the good build. (sorry I took so long to test)
Flags: needinfo?(tohellwithutube)
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
Flags: needinfo?(tohellwithutube)

Comment 29

5 years ago
yes that one has the bug
Flags: needinfo?(tohellwithutube)
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.
Ok, here's the next build to try, Douglas:

http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.54106990fcd8.zip
Flags: needinfo?(tohellwithutube)

Comment 32

5 years ago
that build has the bug too
Flags: needinfo?(tohellwithutube)

Comment 33

5 years ago
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
(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.
Flags: needinfo?(tohellwithutube)

Comment 35

5 years ago
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
Flags: needinfo?(tohellwithutube)
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.
Flags: needinfo?(tohellwithutube)

Comment 37

5 years ago
That one doesn't have the bug
Flags: needinfo?(tohellwithutube)
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.
Ok Douglas, how about this one: http://people.mozilla.org/~mconley2/douglasbuilds/firefox-23.0a1.en-US.win32.fe381d10084f.zip

Good or bad?
Flags: needinfo?(tohellwithutube)

Comment 40

5 years ago
that one's bad.
Flags: needinfo?(tohellwithutube)

Comment 42

5 years ago
that one is bad
Flags: needinfo?(tohellwithutube)
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?
Blocks: 853564
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bgirard)
Assignee

Comment 44

5 years ago
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/tnikkel@gmail.com-91692c8f2098/try-win32/firefox-34.0a1.en-US.win32.zip

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-d0d88f6689bd/try-win32/firefox-34.0a1.en-US.win32.zip
Flags: needinfo?(tohellwithutube)

Comment 45

5 years ago
First build has the bug.

Second build does not have the bug.
Flags: needinfo?(tohellwithutube)
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?
Flags: needinfo?(tnikkel)
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bgirard)
Assignee

Comment 47

5 years ago
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/tnikkel@gmail.com-03afd4780230/try-win32/firefox-34.0a1.en-US.win32.zip
Flags: needinfo?(tnikkel) → needinfo?(tohellwithutube)

Comment 48

5 years ago
that build still has the bug
Flags: needinfo?(tohellwithutube)
Any other hunches or ideas, tn?
Flags: needinfo?(tnikkel)

Comment 51

5 years ago
1: GOOD
2: bad
3: bad
4: GOOD
5: bad
6: GOOD
7: GOOD
Flags: needinfo?(tohellwithutube)
Assignee

Comment 52

5 years ago
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.
Assignee

Updated

5 years ago
Component: General → ImageLib
Product: Firefox → Core

Comment 54

5 years ago
1: GOOD
2: bad
3: GOOD
4: bad
5: GOOD
Assignee

Comment 55

5 years ago
(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 57

5 years ago
1: bad
2: bad
3: bad
4: GOOD
5: GOOD
6: GOOD
Flags: needinfo?(tohellwithutube)
Assignee

Comment 58

5 years ago
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.
Assignee

Comment 59

5 years ago
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/tnikkel@gmail.com-ce59016af246/try-win32/firefox-34.0a1.en-US.win32.zip
Flags: needinfo?(tohellwithutube)

Comment 60

5 years ago
GOOD! Did not encounter bug using that build.
Flags: needinfo?(tohellwithutube)
Assignee

Comment 61

5 years ago
comment 58 describes what's happening. This isn't the greatest patch.
Assignee: nobody → tnikkel
Attachment #8470536 - Flags: review?(bugs)
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.)
Attachment #8470536 - Flags: review?(bugs) → review+
Assignee

Comment 63

5 years ago
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.
Sure, but exposing classes differently to the web is rather odd.
Anyhow, not about this bug.
Assignee

Comment 67

5 years ago
Thanks Douglas for your help and patience, it would have been impossible to fix this bug without your help.
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?
Flags: needinfo?(tnikkel)
https://hg.mozilla.org/mozilla-central/rev/878ede98eacb
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Assignee

Comment 70

5 years ago
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.
Flags: needinfo?(tnikkel)
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.
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.
Assignee

Comment 73

5 years ago
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
Attachment #8470536 - Flags: approval-mozilla-beta?
Attachment #8470536 - Flags: approval-mozilla-aurora?
Flags: needinfo?(tnikkel)
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.
Attachment #8470536 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
Attachment #8470536 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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? :)
Flags: needinfo?(tohellwithutube)
Flags: needinfo?(jbecerra)
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).
Flags: needinfo?(jbecerra)

Comment 80

5 years ago
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

5 years ago
(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.
Marking as Verified on Beta 32, based on comment 81.
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
Flags: needinfo?(gmonster)

Comment 84

5 years ago
(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.
Flags: needinfo?(gmonster)
Thanks again gmnoster.
Marking the bug as verified on:

FF 33.0b2
buildID=20140908190852

per above comment.
Flags: needinfo?(tohellwithutube)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.