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

RESOLVED FIXED

Status

()

Core
Graphics
--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: xtc4uall, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Reporter)

Description

8 years ago
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: --- → ?
(Reporter)

Comment 1

8 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

8 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
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

8 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

Comment 6

8 years ago
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

Comment 7

8 years ago
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

8 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

Comment 8

8 years ago
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...).
(Reporter)

Updated

8 years ago
Duplicate of this bug: 595566
Duplicate of this bug: 595202

Comment 11

8 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

8 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

8 years ago
Also seen this with layers activated on Thinkpad T61 on Intel 965 chipset on XP SP3.

Comment 14

8 years ago
Opening a new window with Ctrl-N usually works as a bypass.

Comment 15

8 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

8 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

8 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.
Status: NEW → RESOLVED
Last Resolved: 8 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.

Comment 21

8 years ago
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.