Closed Bug 1564514 Opened 5 years ago Closed 5 years ago

WebRender in v68 causes text in inactive tabs to be invisible (caused by userChrome.css)

Categories

(Core :: Graphics: WebRender, defect, P2)

68 Branch
Desktop
Windows 10
defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- disabled
firefox67 --- disabled
firefox68 --- disabled
firefox69 --- disabled
firefox70 --- disabled

People

(Reporter: rseiler2002, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached file trouble.txt β€”

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.

Priority: -- → P1

Do you have any idea why WebRender was disabled in 67? Given your hardware configuration I would have expected it to be enabled.

Flags: needinfo?(rseiler2002)

I also noticed that background color for inactive tabs is not the usual dark color? What did you change to get that effect?

(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."

Flags: needinfo?(rseiler2002)

(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.

(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;
    }
  }
}

(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.

OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Summary: WebRender in v68 causes text in inactive tabs to be invisible → WebRender in v68 causes text in inactive tabs to be invisible (caused by userChrome.css)
Blocks: wr-69
Priority: P1 → P2
Attached file userChrome.css β€”

Since bug 1541233 fix, userChrome.css is not loaded by default. Needs to set pref toolkit.legacyUserProfileCustomizations.stylesheets=true.

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).

transparent backgournd color is actually not supported, since window is not transparent on win10 Firefox. Then the transparent color becomes white without compositor window.

Blocks: wr-70
No longer blocks: wr-69
See Also: → 1570879

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.

Status: UNCONFIRMED → RESOLVED
Has STR: --- → yes
Closed: 5 years ago
Keywords: regression
Hardware: x86_64 → Desktop
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: