Regression (suspect main thread compositing only) from bug 900248

Nemo, can you confirm this is with OMTC disabled (i.e., default configuration)?

Hm. Well. I did it in my test profile which I thought was a clean config. I'll be away from that machine until Monday tho.

I could not reproduce this, but it seems totally feasible that bug 900248 broke it. Nemo, when you get to your machine, could you see if this bug reproduces with and without setting the pref 'layers.offmainthreadcomposition.enabled' please?

*sigh* here comes more spam to my bugmail address :-/ normally addresses are masked when not signed in :( Times like this I wish we could edit bugzilla comments. Anyway, sure, first thing Monday.

layers.offmainthreadcomposition.enabled was indeed on default of false and still caused this behaviour. Curiously, if I'm on about:config with a full page of items, unfiltered most everything redraws for some reason. Tab bar, everything. I only get a black border usually along the left and bottom edges. If the list is filtered though, I get black obscuring anything like on any page. If I set layers.offmainthreadcomposition.enabled to true, then the black areas no longer occur, the problem seems "fixed" Well, except then a new problem appears that that fancy new Australis main menu (this is a test profile so I hadn't switched to using the old menu bar) didn't work. I could click on the button, it would focus, but it wouldn't do anything. I have no idea if this is a related problem or not. In case it helps... Graphics Adapter Description: ATI FirePro M5800 Adapter Drivers: ati2dvag Adapter RAM: Unknown Device ID: 0x68c0 DirectWrite: Enabled false (0.0.0.0) Driver Date: 1-15-2011 Driver Version: 8.773.1.1000 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 9 Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (ATI FirePro M5800 Direct3D9 vs_3_0 ps_3_0) windowLayerManagerRemote:false AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend:cairo AzureSkiaAccelerated: 0

Great, thanks for the info! The Australis menu bug is bug 943204, there is a fix, but not landed yet.

Hi Nemo, could you try this build please and see if it fixes your problem? Could you please test that things are OK both with and without OMTC? (The Australis menu bug will still be there with OMTC though). Thanks! http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ncameron@mozilla.com-e494dbc2731a/try-win32/firefox-28.0a1.en-US.win32.installer.exe

Just as broken, no change (OMTC false broke, OMTC true works). BTW, if you have a zip instead of exe for future, that would be a lot more convenient.

(In reply to nemo from comment #6) > *sigh* here comes more spam to my bugmail address :-/ > normally addresses are masked when not signed in :( > > Times like this I wish we could edit bugzilla comments. --> Marked comment 4 & comment 5 private, since they contained one of the nemo's email address (and no other useful information that we'll lose from hiding those comments)

(In reply to nemo from comment #10) > Just as broken, no change (OMTC false broke, OMTC true works). BTW, if you > have a zip instead of exe for future, that would be a lot more convenient. Hi nemo, could you test this build please? Zip is here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ncameron@mozilla.com-a977a4e874ee/try-win32/firefox-28.0a1.en-US.win32.zip Thanks!

try push for that possible fix: https://tbpl.mozilla.org/?tree=Try&rev=a977a4e874ee

Cool. Seems fixed.

\o/ Thanks for testing!

(In reply to nemo from comment #14) > Cool. Seems fixed. Would you mind testing another build please? It is similar to the last one, but slightly nicer, I'm not sure if it will work though. This will be the last one, promise! http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ncameron@mozilla.com-a6e93d83e94c/try-win32/firefox-28.0a1.en-US.win32.zip

Shoot. Totally forgot about this one. Tomorrow might not be near the machine, but will try to recall on the 10th.

So. Short answer. Seems fine with and without OMTC as well. Slightly longer answer. I opened up the test build in a clean profile, opened about:config to double check settings, hit http://slashdot.org and locked screen. On unlock, there was a thin black ribbon between the menu bar and the tab bar (I think. was either there or between the tab bar and the url bar) and a largish black chunk on right side, where some ads (flash?) were playing. These rapidly vanished with no interaction on my part. I don't know if the vanishing was due to site load or just that the cleanup was slightly laggy. I was unable to observe this on the next few attempts after ctrl-shift-r of the site, and on a few other sites I tried. OMTC was also fine, although it felt slightly... snappier? on unlock. The bit where the screen is blank and blue for a brief instant, then the browser appears, that this computer does. That seemed faster with OMTC.

Hrm. Just to be clear. by lock/unlock, I've been hitting ctrl-alt-del, then cancel. Faster than actually locking then typing password. I don't know if those brief black bits were just some artifact of fact browser had just been launched, and was busy loading a site *and* doing that redraw a few seconds later.

Comment on attachment 8349801 [details] [diff] [review] fix mt unlocking and tidy up a bit Review of attachment 8349801 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/d3d9/DeviceManagerD3D9.cpp @@ +689,5 @@ > if (SUCCEEDED(hr)) { > if (IsD3D9Ex()) { > hr = mDeviceEx->CheckDeviceState(mFocusWnd); > > if (FAILED(hr)) { Is it really never worth attempting a ResetEx at D3DERR_DEVICELOST? ::: gfx/layers/d3d9/DeviceManagerD3D9.h @@ +41,3 @@ > DeviceFail, > + // The device is lost, the user should forget the current device manager > + // and create a new one. nit: Not really the device is lost, but the device is lost and cannot be reset.

(In reply to Bas Schouten (:bas.schouten) from comment #21) > Comment on attachment 8349801 [details] [diff] [review] > fix mt unlocking and tidy up a bit > > Review of attachment 8349801 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: gfx/layers/d3d9/DeviceManagerD3D9.cpp > @@ +689,5 @@ > > if (SUCCEEDED(hr)) { > > if (IsD3D9Ex()) { > > hr = mDeviceEx->CheckDeviceState(mFocusWnd); > > > > if (FAILED(hr)) { > > Is it really never worth attempting a ResetEx at D3DERR_DEVICELOST? > I don't know. From the hg history, it looks like we never have, and I'm not keen on spending more time on this issue - given that it only rarely occurs and is not really perf-sensitive.

Comment on attachment 8349801 [details] [diff] [review] fix mt unlocking and tidy up a bit [Approval Request Comment] Bug caused by (feature/regressing bug #): 900248 User impact if declined: black screen when unlocking Windows XP Testing completed (on m-c, etc.): m-c Risk to taking this patch (and alternatives if risky): low-ish risk, but it is not a tested event String or IDL/UUID changes made by this patch: none

I missed the comment change yesterday by forgetting to qref: https://hg.mozilla.org/integration/mozilla-inbound/rev/0c3b24383c8c

Does this new patch verifiably fix the issue?

Comment on attachment 8349801 [details] [diff] [review] fix mt unlocking and tidy up a bit We'll want this on Aurora before merge, can get verification while we're on Beta.

Verified as fixed in latest Aurora 28.0a2 (buildID: 20140203004003) and latest Nightly 29.0a1 (buildID: 20140203030203).