Closed Bug 593674 Opened 14 years ago Closed 14 years ago

transparent/non-updated Chrome/Content UI when resuming from Suspend-to-RAM or lock/unlock windows

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: xtc4uall, Unassigned)

References

Details

(Keywords: regression)

STR: * start Fx * set your PC in Suspend-to-RAM state * recover from that State * look at the Fx Window expected: Fx as normal actual: Chrome/Content UI minus Title Bar is transparent/not updated * it does not help to switch Focus between Apps or resize the Fx Window * only Solution is a Restart of Fx This is with all Hardware/Layers Accel OFF. Moreover this is a recent Regression. Tested with a Build built from http://hg.mozilla.org/mozilla-central/rev/bd474ff6f86c Graphics Adapter Description Radeon X1950 Pro Vendor ID 1002 Device ID 7280 Adapter RAM Unknown Adapter Drivers ati2dvag Driver Version 8.593.100.0 Driver Date 7-21-2009 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Layers Enabled 0/1
blocking2.0: --- → ?
Okay, inspired by Bug 593678 comment 1, i did * start Fx in Safe-mode * Suspend-to-RAM * Recover from it actual = expected. Then i retried STR from comment 0 without starting Fx in Safe-Mode but with setting "layers.accelerate-none" to "true" beforehand and actual = expected, too. Thus explicitly setting "layers.accelerate-none" to "true" is a Workaround too.
Regression Range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124 what includes Bug 590599. Setting the now renamed "mozilla.widget.accelerated-layers" Pref to "true" in the Builds before does not trigger the Issue.
same problem here Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100906 Firefox/4.0b6pre ID:20100906041818 Mobility Radeon X1450 settings default (like comment #0)
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't even have to suspend to see this. All I have to do is to lock and then unlock Windows to see this. Adapter Description NVIDIA Quadro FX 570 Vendor ID 10de Device ID 040e Adapter RAM Unknown Adapter Drivers nv4_dispDriver Version6.14.11.9178 Driver Date 12-17-2009 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Layers Enabled 1/1 Direct3D 9
Logging back in after Hibernate caused the problems described above for the past few days, but with today's build; when I log back in after Windows goes into screen saver mode Minefield crashes. Build id: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre ID:20100909041137 Crash id's: http://crash-stats.mozilla.com/report/index/bp-580531a9-9691-427b-b08a-f9cf32100909 and bp-07c7270f-f31e-4906-ba9b-554cb2100909 Graphics: Adapter Description NVIDIA GeForce 6200 Vendor ID 10de Device ID 0221 Adapter RAM Unknown Adapter Drivers nv4_dispDriver Version 6.14.12.5896 Driver Date7-9-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 1/1 Direct3D 9
Same problem on recent SeaMonkey nighty. I can reproduce simply with ctl-alt-del which brings up task control box, then cancel out of that back to desktop. SM or Fx is then hosed. Windows+L (lock screen) also does it -- something I do regularly. No need for hibernation or sleep. Display controller is a Nvidia Quadro NVS 280.
Summary: transparent/non-updated Chrome/Content UI when resuming from Suspend-to-RAM → transparent/non-updated Chrome/Content UI when resuming from Suspend-to-RAM or lock/unlock windows
I see a new bug attached to the crashes I listed above https://bugzilla.mozilla.org/show_bug.cgi?id=595154. From what it looks like it might fix this problem. Bug fix, says it will Recreate/clean/update D3D9 when needed &/ 'on device reset' (which are involved: logging back in, coming out sleep...).
Bug 595154 does not fix this problem. It stops the crashes I was receiving mentioned in Comment #6, but the screen is back to being blank, like Comment #0 mentioned.
It looks like the following bug is a duplicate of this bug: Bug 593939 - Dead browser windows after OS "lock" It looks like that bug is receiving more developer attention, but this bug was filed first. If they are duplicate, should one be marked Dup?
Depends on: 593939
Also seen this with layers activated on Thinkpad T61 on Intel 965 chipset on XP SP3.
Opening a new window with Ctrl-N usually works as a bypass.
I'm not having this problem with today's build. Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre
Still present on Intel 965 on XP SP3. Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre Built from http://hg.mozilla.org/mozilla-central/rev/268ef4ccb5ff Interesting to note that this build has much more consistent "GPU Accelerated Windows" numbers than previous builds... I'm getting 4/4 Direct3D 9 now, previous best was maybe 1/3 (and often 0/0).
Fixed (as filed per Comment 0 by me) within: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b9ff2a9339e2&tochange=10257eea7533 => Bug 596489 If somebody (still) see similar Symptoms after that, please file a new/your own Bug.
Status: NEW → RESOLVED
Closed: 14 years ago
Depends on: 596489
No longer depends on: 593939
Resolution: --- → FIXED
Hey, for those of us not quite as technical, which build date does that mean it should be fixed in. does that mean it landed in wednesday's build? thursday's? Thanks!
Thursday's build (sep 16) should have the fix.
shaver - thanks! Just got a see through update window today.
Bug 593939 open for on-going problems.
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.