User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre It's the return of the various "black screen" problems again on XP once the screen lock happens. The trick with this problem is to partially cover the window with another application. Built from http://hg.mozilla.org/mozilla-central/rev/c20f34eefa5d Reproducible: Always Steps to Reproduce: 1. Have a normal working Minefield Nightly build 2. Open up an application that partially obscures the Minefield window 3. Press CTRL - ALT - DEL to bring up screen lock window 4. Don't bother locking the desktop, just press ESC to return to the previous view 5. Examine the state of the window Actual Results: The interior of the window is black. The view can be recovered by either resizing the window or opening a new one Expected Results: The window should not go black when returning from the screen lock Screenshots to appear in a minute. Adapter Description Mobile Intel(R) 965 Express Chipset Family Vendor ID 8086 Device ID 2a02 Adapter RAM UnknownAdapter Drivers igxprd32 Driver Version 18.104.22.16818 Driver Date 1-13-2010 Direct2D Enabled Blocked on your graphics card because of unresolved driver issues. DirectWrite Enabled false WebGL RendererTransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 3 2011 03:43:30) GPU Accelerated Windows 2/2 Direct3D 9
Note that the only reason I used Messenger to cause this was that it was the first application I saw it happening with. Notepad also causes the same effect. A non-obscured Minefield does not show this black interior problem.
This was supposed to be fixed by bug 604647. Adding blocking that bug for visibility there.
Can you get a Regression Window? http://harthur.github.com/mozregression/ Does a Driver Update help?
I suspect this regressed with the landing of bug 621601. Presumably the empty transaction upon window unlock is not being refused, investigating.
Hmm, that's not true, this didn't land yet!
Created attachment 500932 [details] [diff] [review] Empty valid region on CleanResources We stopped emptying the valid region when creating new textures. Instead we asserted the valid region was empty on recreation. This assertion is firing here, we should empty the valid region on CleanResources.
Assignee: nobody → bas.schouten
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #500932 - Flags: review?(roc)
Attachment #500932 - Flags: review?(roc) → review+
blocking2.0: ? → betaN+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
WFM now with Gecko/20110104 Firefox/4.0b9pre
Status: RESOLVED → VERIFIED
In what Firefox version is this supposed to be fixed? It happens for me with 4.0b10 and a fresh profile. Windows XP SP3 32-bit, nVidia Quadro NVS 210S graphics adapter.
You need to log in before you can comment on or make changes to this bug.