Closed Bug 988862 Opened 8 years ago Closed 8 years ago

Flashing black boxes when scrolling on Windows

Categories

(Core :: Graphics, defect)

29 Branch
x86
Windows 7
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox29 + verified
firefox30 --- verified
firefox31 --- verified

People

(Reporter: mconley, Assigned: mattwoodrow)

References

Details

(Keywords: regression)

Attachments

(1 file)

First heard about this while lurking in Mozillazine[1].

STR (steps 3-5 might take a few tries - I get it maybe once every 5 times)

1) Create a Firefox profile with many tabs - enough so that session restore has to take a little bit loading it. I had about 44 tabs when I reproduced this.
2) Go to Menu > Options, and in General, next to "When [brandname] starts", tell it to "Show my windows and tabs from last time"
3) Shut down the browser
4) Start up the browser, while repeatedly jamming Windows' "Show Desktop" button (that thing in the bottom right of the task bar).
5) Attempt to scroll a scrollable page.

AR:

Lots of black flashiness in the scrolling of the content. Scrolling chrome, like the tabstrip, doesn't seem to have this problem.

ER:

No flashy.


My screencap software doesn't convey this properly, so I took a video with my phone. I'll post a link when it's done encoding.

I put this in General, because I have no idea if this is a Graphics, Layout or Windows Widget bug. We can move it to the right place once we figure it out.

[1]: http://forums.mozillazine.org/viewtopic.php?p=13435841&sid=e74d83a897aab3a21b039be10b41fe3d#p13435841
Video demonstration: https://vimeo.com/90223753

jrmuizel - do you know what component this bug might fall under?
Flags: needinfo?(jmuizelaar)
Component: General → Graphics
Flags: needinfo?(jmuizelaar)
Product: Firefox → Core
Is this a regression?
I don't know - I just heard about it while reading a Mozillazine thread, and was able to reproduce it.

Unsure when it got introduced, but it's (at least) in the current Aurora branch (Fx 30).
Duplicate of bug 951885 and perhaps related to bug 975555?
I can sometimes reproduce this at my desk. Let me know if you want to check it out IRL.
Duplicate of this bug: 989435
Per bug 989435, this is now affecting beta as well. It sounds like it's due to something that's being uplifted...

Marc, do you know what version of beta you had before the problem appeared? Would you be willing to try some of the ones from http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ (I'm guessing you were already on 29.0b1/b2, not on 28 - did you have the "curved" tabs before you got the latest update already?) to help us figure out what's causing this? Thank you!
Flags: needinfo?(marc)
(In reply to :Gijs Kruitbosch (no internet 29 Mar - 6 Apr) from comment #7)
> Per bug 989435, this is now affecting beta as well. It sounds like it's due
> to something that's being uplifted...
> 
> Marc, do you know what version of beta you had before the problem appeared?
> Would you be willing to try some of the ones from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ (I'm guessing you
> were already on 29.0b1/b2, not on 28 - did you have the "curved" tabs before
> you got the latest update already?) to help us figure out what's causing
> this? Thank you!

Hi,

I am on the beta channel and have the 29 beta quite a while. I am not quite sure which 29 beta build I have. How can I determine the exact build?
Flags: needinfo?(marc)
(In reply to Marc Nesello from comment #8)
> (In reply to :Gijs Kruitbosch (no internet 29 Mar - 6 Apr) from comment #7)
> > Per bug 989435, this is now affecting beta as well. It sounds like it's due
> > to something that's being uplifted...
> > 
> > Marc, do you know what version of beta you had before the problem appeared?
> > Would you be willing to try some of the ones from
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ (I'm guessing you
> > were already on 29.0b1/b2, not on 28 - did you have the "curved" tabs before
> > you got the latest update already?) to help us figure out what's causing
> > this? Thank you!
> 
> Hi,
> 
> I am on the beta channel and have the 29 beta quite a while. I am not quite
> sure which 29 beta build I have. How can I determine the exact build?

You can go to the about:buildconfig page from the URL bar, and it'll list a rev link. Mine says: Built from https://hg.mozilla.org/releases/mozilla-beta/rev/fceb90d30601, for instance. If you download and try the builds from the b2/b3 directories and let us know if they all have this issue or only some of them (and include the revlinks for which ones do and which ones don't) that'd be great!
Flags: needinfo?(marc)
(In reply to :Gijs Kruitbosch (no internet 29 Mar - 6 Apr) from comment #9)
> (In reply to Marc Nesello from comment #8)
> > (In reply to :Gijs Kruitbosch (no internet 29 Mar - 6 Apr) from comment #7)
> > > Per bug 989435, this is now affecting beta as well. It sounds like it's due
> > > to something that's being uplifted...
> > > 
> > > Marc, do you know what version of beta you had before the problem appeared?
> > > Would you be willing to try some of the ones from
> > > http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ (I'm guessing you
> > > were already on 29.0b1/b2, not on 28 - did you have the "curved" tabs before
> > > you got the latest update already?) to help us figure out what's causing
> > > this? Thank you!
> > 
> > Hi,
> > 
> > I am on the beta channel and have the 29 beta quite a while. I am not quite
> > sure which 29 beta build I have. How can I determine the exact build?
> 
> You can go to the about:buildconfig page from the URL bar, and it'll list a
> rev link. Mine says: Built from
> https://hg.mozilla.org/releases/mozilla-beta/rev/fceb90d30601, for instance.
> If you download and try the builds from the b2/b3 directories and let us
> know if they all have this issue or only some of them (and include the
> revlinks for which ones do and which ones don't) that'd be great!

Hi Gijs,

I finally could reproduce it with Mikes instructions.
The rev link is http://hg.mozilla.org/releases/mozilla-esr24/rev/6756aa79a839

Thanks and best regards
Marc
Flags: needinfo?(marc)
Sorry, somehow I copied a wrong rev url.
THe right one is  29b3 (https://hg.mozilla.org/releases/mozilla-beta/rev/683f3c7580b8)
(In reply to Marc Nesello from comment #11)
> Sorry, somehow I copied a wrong rev url.
> THe right one is  29b3
> (https://hg.mozilla.org/releases/mozilla-beta/rev/683f3c7580b8)

No worries. But to be clear - this one is broken, and b2 isn't, is that what you're saying? :-)
Flags: needinfo?(marc)
(In reply to :Gijs Kruitbosch (no internet 29 Mar - 6 Apr) from comment #12)
> (In reply to Marc Nesello from comment #11)
> > Sorry, somehow I copied a wrong rev url.
> > THe right one is  29b3
> > (https://hg.mozilla.org/releases/mozilla-beta/rev/683f3c7580b8)
> 
> No worries. But to be clear - this one is broken, and b2 isn't, is that what
> you're saying? :-)

Exactly. I tried several times, but couldn't reproduce it with 29b2 (https://hg.mozilla.org/releases/mozilla-beta/rev/fceb90d30601)
Flags: needinfo?(marc)
I was able to reproduce on 29b2.

I'm going to see if this is in release.
Able to reproduce it in beta 1 as well.

No luck yet on current release, but I'll keep trying for the next few minutes.
No luck reproducing on release.

I went back and tested some Nighty's. I was able to reproduce this back to the 2014-02-14 Nightly, but not before.

Is anybody able to reproduce this bug on a Nightly before 2014-02-14?
Flags: needinfo?
Operating on (the possibly incorrect) assumption that the regression was introduced on 2014-02-14, here's our changeset range:

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-02-13&enddate=2014-02-14
Flags: needinfo?
I came to this regression-range:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e9378c4abc75&tochange=e34283cf0b42

The correct bug listed there would be https://bugzilla.mozilla.org/show_bug.cgi?id=805406 not 806406

With 10 tries each, I can't trigger the flashes with the good build, and about 7 out of 10 times with the bad build.
And it's easier to trigger them when you accidentally also trigger the date-popup with every other click from the taskbar.

The activity-indicators can turn ugly with the good build, but without the black flashes of the bad build: http://i.imgur.com/nP0sPTT.png

When the bug hits (also in the good build), this is shown in the browser console:
>Direct3D 9 DeviceManager Initialized Successfully.
>Driver: nvd3dum.dll
etc.

about:support shows...

before triggering the bug:
GPU Accelerated Windows: 1/1 Direct3D 10

after triggering the bug:
GPU Accelerated Windows: 0/1 Basic
Excellent - thanks Elbart.

Assuming this was not somehow caused by Neil's string work, do you have any idea how bug 805406 might be causing this Bas?
Blocks: 805406
Flags: needinfo?(bas)
I can randomly reproduce this issue a different way. I'm currently running Firefox 29 beta and Nightly setup to use two different profiles (default for Firefox, nightly for Nightly) with the ability to have both open at the same time using -no-remote. Anyways, I've noticed if I have both open and minimized for awhile, when I restore the windows (of either browser, again it's random) this issue shows up big time but it's random. I'll try to work out a means to reproduce it on demand.
Just noticed this when upgrading from the 2014-03-30 to the 2014-03-31 nightly. I have never seen this issue prior to the 31 nightly. It's pretty obvious, not something that I'd have missed.

It's pretty bad, some of the flickering is almost seizure inducing!

Hopefully this may aid in discovering the cause. I've downgraded for now. If there is anything specific information that is needed then I'll keep an eye out here.
To me, flashing started only in today's build. If it is being caused by bug 805406, the trigger has to be something that landed in past 24 hours.
FYI, beta 6 is going to build today...
(In reply to Mike Conley (:mconley) from comment #19)
> Excellent - thanks Elbart.
> 
> Assuming this was not somehow caused by Neil's string work, do you have any
> idea how bug 805406 might be causing this Bas?

Nothing obvious jumps to mind, but the behavior here isn't always obvious, so I wouldn't be willing to rule it out.
Flags: needinfo?(bas)
Duplicate of this bug: 992495
Refer to Comment#18 and Bug 991708 comment#0,
Suddenly, the layers acceleration seems to become disabled without user interaction.
I have never experienced this problem.
However, according to comment #28, I reproduced this situation with a manual.

Steps To Reproduce (emulated the situation with a manual):
1. Start Firefox with HWA on
2. Set layers.acceleration.disabled = true in about:config
3. Open new window (Ctrl+N)
4. Scroll page(about:support)

Actual Results:
Flicker with black box


Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/32fef9133b8b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140212162724
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e34283cf0b42
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140212180023
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=32fef9133b8b&tochange=e34283cf0b42

Triggered by:e34283cf0b42	Bas Schouten — Bug 806406: Remove some lingering references to gfxD2DSurface. r=jrmuize
(NOTE, the bug" is wrong, it should be Bug 805406)



Why does sudden the layers acceleration become disabled?
Flags: needinfo?(bas)
Great job finding more reliable STR, Alice!
or Matt Woodrow, do you know what might be happening here?
Flags: needinfo?(matt.woodrow)
I'm about 87% sure this is the issue, can someone please test this for me :)
Flags: needinfo?(matt.woodrow)
Sure, testing...
(In reply to Matt Woodrow (:mattwoodrow) from comment #32)
> Created attachment 8403658 [details] [diff] [review]
> Always treat direct2d as GDI when drawing directly to the window
> 
> I'm about 87% sure this is the issue, can someone please test this for me :)

This appears to fix the bug - I tested both with Alice's steps, as well as the steps from comment 0.

I _do_ notice, however, that the window caption buttons (minimize, maximize, close) go a bit blinky when I scroll up on Windows 7 with Alice's steps.

But this is _substantially_ better than the flash-dance we were doing before.
Sweet! Thanks for checking it Mike.

I don't have any theories about what would cause the window caption buttons to flash. I wonder if this is also part of the regression or if we already had this bug without hardware acceleration enabled.

A video of that would be awesome :)
Flags: needinfo?(bas)
Attachment #8403658 - Flags: review?(jmuizelaar)
Note: HWA is enabled on my machine and under normal circumstances all my windows are hardware accelerated. I only get this bug once one of the windows loses its hardware-accelerated status (seemingly forever?). Is that behavior intended, and if so, is it a known issue caused by a certain plugin or addon?
Attachment #8403658 - Flags: review?(jmuizelaar) → review+
https://hg.mozilla.org/mozilla-central/rev/d17583440ac0
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
1.) The flashing might be gone, but following the steps of comment 0 still leads to HWA being deactivated during the session-loading.
Tested with hourly from http://download-origin.cdn.mozilla.net/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1397042268/
Although it's fine that the full-screen-flickering is gone, any slowness might not be obviously considered to be the fault of lacking HWA (as the checkbox in the options is ticked), but Firefox "just being slow".

When the bug has happened, opening a new window from the hamburglar-menu and visiting about:support shows that the new window is HWA'd ("1/2 Direct3D 10"). Closing that window, and the count is back to "0/1 Basic".

2.) The flickering of the caption-buttons when HWA is disabled may have this regression-window:

m-c
Last good revision: 8122ffa9e1aa (2014-03-06)
First bad revision: b0e7f63c2138 (2014-03-07)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8122ffa9e1aa&tochange=b0e7f63c2138

m-i
Last good revision: 969361ceb21d
First bad revision: 36e45a68452b
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=969361ceb21d&tochange=36e45a68452b

36e45a68452b	Matt Woodrow — Bug 940455 - Add LayerManager functonality to clear out a portion of the window for the OS to paint. r=roc,Bas
the bug still happens for me with Firefox 29 BETA update 6
(In reply to Elbart from comment #39)
> 1.) The flashing might be gone, but following the steps of comment 0 still
> leads to HWA being deactivated during the session-loading.
> Tested with hourly from
> http://download-origin.cdn.mozilla.net/pub/firefox/tinderbox-builds/mozilla-
> inbound-win32/1397042268/
> Although it's fine that the full-screen-flickering is gone, any slowness
> might not be obviously considered to be the fault of lacking HWA (as the
> checkbox in the options is ticked), but Firefox "just being slow".
> 
> When the bug has happened, opening a new window from the hamburglar-menu and
> visiting about:support shows that the new window is HWA'd ("1/2 Direct3D
> 10"). Closing that window, and the count is back to "0/1 Basic".
> 


Please file a new bug.



> 2.) The flickering of the caption-buttons when HWA is disabled may have this
> regression-window:
> 
> m-c
> Last good revision: 8122ffa9e1aa (2014-03-06)
> First bad revision: b0e7f63c2138 (2014-03-07)
> Pushlog:
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=8122ffa9e1aa&tochange=b0e7f63c2138
> 
> m-i
> Last good revision: 969361ceb21d
> First bad revision: 36e45a68452b
> Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=969361ceb21d&tochange=36e45a68452b
> 
> 36e45a68452b	Matt Woodrow — Bug 940455 - Add LayerManager functonality to
> clear out a portion of the window for the OS to paint. r=roc,Bas

Please file a new bug.
Flags: needinfo?(elbart)
No interest.
Flags: needinfo?(elbart)
here is an easy way to repro this very quickly

just open firefox in a few times
http://www.youtube.com/watch?v=LJxeEcF8n1M
(In reply to cowboy from comment #40)
> the bug still happens for me with Firefox 29 BETA update 6

Yep - the patch hasn't been uplifted yet - but it should be in either the latest Nightly, or tomorrow's Nightly. We'll see about getting this uplifted to the Beta and Aurora branches soon.

(In reply to cowboy from comment #43)
> here is an easy way to repro this very quickly
> 
> just open firefox in a few times
> http://www.youtube.com/watch?v=LJxeEcF8n1M

Thanks - though I have to admit that Alice's steps from comment 29 are a little shorter / easier.
(In reply to Matt Woodrow (:mattwoodrow) from comment #35)
> Sweet! Thanks for checking it Mike.
> 
> I don't have any theories about what would cause the window caption buttons
> to flash. I wonder if this is also part of the regression or if we already
> had this bug without hardware acceleration enabled.
> 
> A video of that would be awesome :)

Done: https://www.youtube.com/watch?v=0EYzC7kZwRE
Also, how risky would you say an uplift would be for Aurora and Beta? This is a pretty horrible state for our users to get into.
Flags: needinfo?(matt.woodrow)
Addendum to comment 39 point 1:

This is happening right before the message in the browser-console regarding D3D9 being initialized (as mentioned in comment 18):

(f50.ed8): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0019eae8 ebx=08c7e4b4 ecx=00000003 edx=00000000 esi=0019ef24 edi=00000000
eip=75afc41f esp=0019eae8 ebp=0019eb38 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
KERNELBASE!RaiseException+0x58:
75afc41f c9              leave
0:000> g
(f50.ed8): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0019ec44 ebx=00000000 ecx=00000003 edx=00000000 esi=00000000 edi=08c7e1c0
eip=75afc41f esp=0019ec44 ebp=0019ec94 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
KERNELBASE!RaiseException+0x58:
75afc41f c9              leave
0:000> g
(f50.ed8): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0019ef14 ebx=08d1f960 ecx=00000003 edx=00000000 esi=80070057 edi=00100260
eip=75afc41f esp=0019ef14 ebp=0019ef64 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
KERNELBASE!RaiseException+0x58:
75afc41f c9              leave
0:000> g
Direct3D 9 DeviceManager Initialized Successfully.
Driver: nvd3dum.dll
Description: NVIDIA GeForce GT 640 

The stuff happening before these three exception is never the same. Once it was a pack of CSS-warnings, the other time a bunch of ModLoad-messages.
Comment on attachment 8403658 [details] [diff] [review]
Always treat direct2d as GDI when drawing directly to the window

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 805406
User impact if declined: Horrible flashing if user has h/w acceleration disabled.
Testing completed (on m-c, etc.): Confirmed locally.
Risk to taking this patch (and alternatives if risky): Very low risk.
String or IDL/UUID changes made by this patch: None
Attachment #8403658 - Flags: approval-mozilla-beta?
Attachment #8403658 - Flags: approval-mozilla-aurora?
Flags: needinfo?(matt.woodrow)
Depends on: 994428
Blocks: 994432
(In reply to Elbart from comment #42)
> No interest.

Thanks for all your help!

I've filed bug 994432 and bug 994428 for the remaining issues.

It's important to keep each bug focused on one issue, because otherwise we tend to lose track of what has and hasn't been fixed.
Assignee: nobody → matt.woodrow
Attachment #8403658 - Flags: approval-mozilla-beta?
Attachment #8403658 - Flags: approval-mozilla-beta+
Attachment #8403658 - Flags: approval-mozilla-aurora?
Attachment #8403658 - Flags: approval-mozilla-aurora+
im curious is this flash flicker box bug now fixed?
Will be this fixed in Update 7 for ff29?
(In reply to cowboy from comment #51)
> im curious is this flash flicker box bug now fixed?
> Will be this fixed in Update 7 for ff29?

Yes, the patch has landed for Nightly, Aurora and Beta. The fix should be included in the next Beta build, and tomorrow's Aurora build.
ah nice to hear,
thank you for the answer
cowboy, could you help us verify this bug is fixed using the Fx29b7 builds which should be coming out tomorrow morning?
QA Whiteboard: [qa+]
of course
in Germany is it already 14:00, and no update yet

is the updated delayed?
cowboy, most of the Mozilla QA team is in California. So, the official beta update is going to arrive later today.
If you want to test the beta7 right now, you can find it here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/29.0b7/
The bug is fixed in beta7, ya!.

Thank you
I'm 100% sure this bug is fixed with update7.

good job, and thanks again
Verified as fixed using the following environment:

FF 30 Aurora
Build Id:20140428004000
OS: Win7 x64

FF 31 Nightly
Build id:20140428030203
OS: Win7 x64
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
You need to log in before you can comment on or make changes to this bug.