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)
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
Updated•14 years ago
|
blocking2.0: --- → ?
Reporter | ||
Comment 1•14 years ago
|
||
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.
Reporter | ||
Comment 2•14 years ago
|
||
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.
Keywords: regressionwindow-wanted
Reporter | ||
Comment 3•14 years ago
|
||
(In reply to comment #2)
> Regression Range:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124
> what includes Bug 590599.
Verified now by checking the Hourly Builds:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=404b79632ff4&tochange=52546421427a
Comment 4•14 years ago
|
||
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
Comment 5•14 years ago
|
||
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.
Updated•14 years ago
|
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...).
Comment 11•14 years ago
|
||
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.
Comment 12•14 years ago
|
||
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?
Comment 13•14 years ago
|
||
Also seen this with layers activated on Thinkpad T61 on Intel 965 chipset on XP SP3.
Comment 14•14 years ago
|
||
Opening a new window with Ctrl-N usually works as a bypass.
Comment 15•14 years ago
|
||
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
Comment 16•14 years ago
|
||
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).
Reporter | ||
Comment 17•14 years ago
|
||
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.
Comment 18•14 years ago
|
||
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.
Comment 20•14 years ago
|
||
shaver - thanks!
Just got a see through update window today.
Comment 21•14 years ago
|
||
Bug 593939 open for on-going problems.
Updated•14 years ago
|
blocking2.0: ? → final+
You need to log in
before you can comment on or make changes to this bug.
Description
•