604647 - [d3d] Firefox Desktop Notification window is black after desktop lock with Intel Graphics card on XP

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Barry Marshall]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre

This is likely just another version of Bug 593678, so it should be a similar fix but a different location in the code.

If you hide the Minefield window with another application, lock the XP Desktop,  and get a Desktop Notification after you unlock the desktop again, you get a black Notification window.

This blackness then affects the rest of the Minefield windows.  The usual tricks of starting another tab or opening another window don't resolve the blackness.   Exit Minefield and restart is required to fix.


Reproducible: Always

Steps to Reproduce:
1.Have Minefield installed on a unit with Intel graphics chip  (my usual Thinkpad T61 with XP SP3, X3100 chipset, and latest Lenovo drivers)
2.Start a big download that may take a minute or two to complete
3.Completely cover Minefield with another application   (Notepad in my example)
4.Press CTRL-ALT-DEL and lock the desktop
5.Unlock the desktop
6.Do not touch anything or change the window order and wait for the download to complete
7.Observe the Desktop Notification popup
Actual Results:  
The Desktop Notification is black.

Expected Results:  
The Desktop Notification should set the initial D3D9 window graphics parameters correctly so that that we get a non-black window.

Graphics Adapter Description: Mobile Intel(R) 965 Express Chipset Family
Vendor ID 8086
Device ID 2a02
Adapter RAM UnknownAdapter 
Drivers igxprd32
Driver Version 6.14.10.5218
Driver Date 1-13-2010
Direct2D Enabled Blocked on your graphics card because of unresolved driver issues.
DirectWrite Enabled false
GPU Accelerated Windows 1/1 Direct3D 9

Comment 1

[Barry Marshall]

Attachment: Notepad with a black Notification Window overlaying it

Look to the lower-right of this large image.

Comment 2

[Bas Schouten (:bas.schouten)]

Ooh, I think I might know why this is. Hmm. This should block Final, personally I'm not sure it blocks a beta.

Comment 3

[Alice0775 White]

Regression window;

user_pref("mozilla.widget.render-mode", 0);
user_pref("gfx.direct2d.disabled", true);
user_pref("layers.accelerate-all", true);
user_pref("mozilla.widget.accelerated-layers", true);

Graphics        
Adapter Description: VMware SVGA II
Vendor ID: 15ad
Device ID: 0405
Adapter RAM: Unknown
Adapter Drivers: vmx_fb
Driver Version: 11.6.0.35
Driver Date: 4-21-2010
Direct2D Enabled: false
DirectWrite Enabled: false
GPU Accelerated Windows: 1/1 Direct3D 9

Works:
http://hg.mozilla.org/mozilla-central/rev/404b79632ff4
Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827194434
Fails:
http://hg.mozilla.org/mozilla-central/rev/2715808a3010
Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827210242
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=404b79632ff4&tochange=2715808a3010

Umm, there are test, pref name and  null check....???

Comment 4

[Scoobidiver (away)]

The first appearance of this issue has been fixed by bug 600388 that has been landed on 10/4/2010.
So the regression range must be found after this date.

Comment 5

[Bas Schouten (:bas.schouten)]

I believe the problem here was Bug 614111. I'm going to resolve it as a duplicate of that, since it hasn't been obviously seen since then. Please re-open if it's still there.

Comment 6

[Barry Marshall]

Nope, I can still recreate this problem with http://hg.mozilla.org/mozilla-central/rev/f11f7ed625ba .   Screenshots coming.

Once I get the failed popup appearing on my screen the rest of the browser window interiors become black as well.  Starting a new window does not resolve the problem and I must close down and restart the browser to recover.

Adapter Description Mobile Intel(R) 965 Express Chipset Family
Vendor ID 8086
Device ID 2a02
Adapter RAM Unknown
Adapter Drivers igxprd32Driver Version6.14.10.5218
Driver Date 1-13-2010
Direct2D Enabled Blocked on your graphics card because of unresolved driver issues.
DirectWrite Enabled false
GPU Accelerated Windows 1/1 Direct3D 9

Comment 7

[Barry Marshall]

Attachment: Hidden Firefox puts up a Notification Window in lower-right that's all black

Not sure if it makes a difference, but my Taskbar is set to auto-hide

Comment 8

[Barry Marshall]

Attachment: Firefox windows after the black pop-up on hidden Firefox does me in

Comment 9

[Barry Marshall]

I should also note that a visible Firefox before and after lock does not suffer this problem.

Comment 10

[Bas Schouten (:bas.schouten)]

Hrm, I've tried everything I could think of, VM, Windows 7 Aero, Windows 7 Basic. I've really tried to follow the STR to the letter. But I just can't reproduce this bug, everything seems to come up as one would expect it to and work nicely.

This probably isn't hard to fix if we can reproduce it somewhere with the Direct3D debug layer! We'll have to find a machine somewhere that has this issue. Judging from the STR this must be related to initial SwapChain creation for the new window failing  which is expected. But locally for me as by design when it tries to draw the device is reset at http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d9/DeviceManagerD3D9.cpp#121 and then the SwapChain is created as expected.

Comment 11

[Barry Marshall]

Are there any debug or Try builds I can run here to get you a better log of the problem?

Comment 12

[Bas Schouten (:bas.schouten)]

I've found a machine in the QA lab that reproduces this problem and I've been analyzing it with a debugger. What happens here is very interesting and seems to be a bug somewhere, but I have not yet thought of a work-around. It seems that when a new window is created while no window has been visible so far TestCooperativeLevel will permanently report S_OK even though the device needs to be reset.

Locking the screen again and unlocking it will properly trigger the D3DERR_DEVICENOTRESET and fix the issue.

Comment 13

[Bas Schouten (:bas.schouten)]

Attachment: Never try and create a swap chain when the device is lost

I've discovered that is we call CreateAdditionalSwapChain while the device is lost the device goes into an invalid state that it doesn't get out of until it is lost again.

The lowest-risk solution here is to fail creating our SwapChainD3D9 when the device is lost. This means that for windows created while the screen is locked on Windows XP for example we wouldn't get hardware acceleration. I don't think that's a big issue.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 498482 [details] [diff] [review]
Never try and create a swap chain when the device is lost

Sounds decent enough.

Comment 15

[Bas Schouten (:bas.schouten)]

http://hg.mozilla.org/mozilla-central/rev/b71a05bcd2f5