WebRender in v68 causes text in inactive tabs to be invisible (caused by userChrome.css)
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
People
(Reporter: rseiler2002, Unassigned)
References
Details
(Keywords: regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.102 Safari/537.36
Steps to reproduce:
Nothing more than upgraded to v68.
Actual results:
I noticed that the tab area, with the exception of the active tab, was black. This makes seeing inactive tabs difficult, since only the favicon is visible:
https://i.imgur.com/s5vt7nv.png
It normally looks like this:
https://i.imgur.com/dFz58VM.png
Expected results:
Still have the ability to see all tabs. I traced the problem to WebRender being enabled, which it was automatically in this version.
Setting "gfx.webrender.force-disabled" to True and restarting Firefox resolved the problem. I reverted this change, however, before saving out the Troubleshooting information that you'll find attached.
I should note that I saw the same issue when I temporarily enabled WebRender in v67.
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Do you have any idea why WebRender was disabled in 67? Given your hardware configuration I would have expected it to be enabled.
Comment 2•5 years ago
|
||
I also noticed that background color for inactive tabs is not the usual dark color? What did you change to get that effect?
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)
Do you have any idea why WebRender was disabled in 67? Given your hardware configuration I would have expected it to be enabled.
Yes, in the beginning (when v67 was released), it was said that "Only 5% of compatible Firefox systems will have WebRender switched on, the remaining 95% stay on the existing compositor for now."
Comment 4•5 years ago
|
||
(In reply to rseiler2002 from comment #3)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)
Do you have any idea why WebRender was disabled in 67? Given your hardware configuration I would have expected it to be enabled.
Yes, in the beginning (when v67 was released), it was said that "Only 5% of compatible Firefox systems will have WebRender switched on, the remaining 95% stay on the existing compositor for now."
The 5% was based on hardware configuration. But we ran a telemetry experiment so it's possible that you ended up in the control group for 67.
Reporter | ||
Comment 5•5 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
I also noticed that background color for inactive tabs is not the usual dark color? What did you change to get that effect?
That was the key. It wasn't because of a theme or extension, but I remember that I had a years-old userChrome.css. Renaming that solved the problem.
The section that pertained must have been this. I'm not sure what the intent was with it these years later.
@media (-moz-os-version: windows-win10) {
#main-window:not([customizing]){
-moz-appearance: -moz-win-glass !important;
background-color: transparent !important;
}
}
}
Comment 6•5 years ago
|
||
(In reply to rseiler2002 from comment #5)
Renaming that solved the problem.
Thanks for testing!
Since bug 1550157 and bug 1541233 toolkit.legacyUserProfileCustomizations.stylesheets must be enabled to be able to use userChrome.css. It would have been nice if about:support included this information.
Comment 7•5 years ago
|
||
Comment 8•5 years ago
|
||
Since bug 1541233 fix, userChrome.css is not loaded by default. Needs to set pref toolkit.legacyUserProfileCustomizations.stylesheets=true.
Comment 9•5 years ago
•
|
||
I could reproduce the problem on Win10 with WebRender. It seems to be related to compositor window usage.
When gfx.webrender.dcomp-win.enabled=false, I did not see the problem. And I also saw the problem with Direct3D11 compositor with double buffering (pref gfx.direct3d11.use-double-buffering=true).
Comment 10•5 years ago
•
|
||
transparent backgournd color is actually not supported, since window is not transparent on win10 Firefox. Then the transparent color becomes white without compositor window.
Updated•5 years ago
|
Comment 12•5 years ago
|
||
According to comment 10 and bug 1570879 comment 3 this seems to be a cantfix/wontfix.
If a userChrome.css user really wants to have transparent windows on Win10, it seems necessary to manually disable gfx.webrender.dcomp-win.enabled and to accept a regression to gain this capability.
Description
•