Closed
Bug 1241363
Opened 9 years ago
Closed 9 years ago
Some context menus or alerts are transparent/empty until moused over.
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox45 | --- | unaffected |
firefox46 | --- | fixed |
People
(Reporter: streetwolf52, Assigned: mchang)
References
Details
(Keywords: regression, Whiteboard: [fixed by backed out Bug 1239861])
Attachments
(3 files)
A very good example is the about:config context menus. Also the menus from the sidebar. I ran a mozregression-gui and came up with this:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1a8fc158b56d42dc118cd8db0881e554068d7aab&tochange=415f713d58b0803cf143f0a605ed79409d57fc1d
Doesn't look like any of these could be the cause but who knows.
Reporter | ||
Updated•9 years ago
|
Component: General → Menus
Reporter | ||
Updated•9 years ago
|
Component: Menus → Graphics
Product: Firefox → Core
Comment 2•9 years ago
|
||
I'm seeing this (in a Win10 VM) not with the menus mentioned in comment 0, but with examples like the Confirm Close ("You are about to close 11 tabs...") or Cancel All Downloads (if a download is in progress) alert that appears when clicking the browser window's close button: the alert appears but its contents doesn't render until I mouse over it.
It doesn't seem to be 100% reproducible for me -- at least once just now, the Confirm Close dialog rendered right away as expected -- but it's happening pretty consistently with the latest inbound build.
Mason, is it possible this could be some kind of compositing issue related to bug 1239861?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Some context menus are transparent until moused over. → Some context menus or alerts are transparent/empty until moused over.
Updated•9 years ago
|
Flags: needinfo?(mchang)
Reporter | ||
Comment 3•9 years ago
|
||
If I turn off HWA the problem doesn't happen.
Comment 5•9 years ago
|
||
Setting layers.acceleration.disabled = true seems fix the problem
status-firefox46:
--- → affected
Component: Graphics → Graphics: Layers
Keywords: regression
OS: Windows 10 → Windows
Reporter | ||
Comment 6•9 years ago
|
||
I can repro the problem 100% of the time in many ways.
Updated•9 years ago
|
Reporter | ||
Comment 7•9 years ago
|
||
So far I'm the only one seeing it in many different places. Perhaps it is dependent on one's graphic drivers as to how it manifests itself?
Graphics
--------
Adapter Description: AMD Radeon (TM) R9 390 Series
Adapter Drivers: aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 4095
Asynchronous Pan/Zoom: wheel input enabled
ClearType Parameters: D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ]
Device ID: 0x67b1
Direct2D Enabled: true
DirectWrite Enabled: true (10.0.10586.0)
Driver Date: 12-23-2015
Driver Version: 15.301.1201.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 00000000
Supports Hardware H264 Decoding: Yes
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(mchang)
Assignee | ||
Comment 8•9 years ago
|
||
It could be bug 1239861, which was backed out for other things. Are you still seeing it on nightly?
Do you have a screenshot as well please? Thanks!
Flags: needinfo?(garyshap)
Reporter | ||
Comment 9•9 years ago
|
||
Flags: needinfo?(garyshap)
Reporter | ||
Comment 10•9 years ago
|
||
Comment 11•9 years ago
|
||
Note that the backout won't hit Nightly until the 2016-01-22 build, AFAICT. However, testing the latest currently-available inbound build, which is after the backout of bug 1239861, I do not see the problem any more.
Reporter | ||
Comment 12•9 years ago
|
||
Reporter | ||
Comment 13•9 years ago
|
||
I am on the latest inbound hourly and still have the problem:
http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64-pgo/1453379543/
Reporter | ||
Comment 14•9 years ago
|
||
(In reply to Gary [:streetwolf] from comment #13)
> I am on the latest inbound hourly and still have the problem:
>
> http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-
> win64-pgo/1453379543/
The backout hasn't made it here yet.
Comment 15•9 years ago
|
||
That doesn't have the backout yet. If you try the build from http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64/1453395202/ I think it'll probably be fixed (though performance will be worse, as that's not a PGO build... those take a lot longer to appear).
Reporter | ||
Comment 16•9 years ago
|
||
While I'm at it is there any difference between the inbound win64-PGO and the normal win64 inbound?
Reporter | ||
Comment 17•9 years ago
|
||
We collided so I got my answer :-)
Comment 18•9 years ago
|
||
Just tested with m-c win32 build cset: https://hg.mozilla.org/mozilla-central/rev/66e07ef46853
This is fixed by backout...
Reporter | ||
Comment 19•9 years ago
|
||
Working again on my end.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → mchang
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: [fixed by backed out Bug 1239861]
Updated•9 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•