Closed Bug 593674 Opened 10 years ago Closed 10 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...).
Duplicate of this bug: 595566
Duplicate of this bug: 595202
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: 10 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.