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

Status: RESOLVED WONTFIX

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

Description

[rseiler2002]

Attachment: 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.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

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

[Jeff Muizelaar [:jrmuizel]]

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

Comment 3

[rseiler2002]

(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

[Jeff Muizelaar [:jrmuizel]]

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

Comment 5

[rseiler2002]

(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

[Jan Andre Ikenmeyer [:darkspirit]]

(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

[Sotaro Ikeda [:sotaro]]

Attachment: userChrome.css

Comment 8

[Sotaro Ikeda [:sotaro]]

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

Comment 9

[Sotaro Ikeda [:sotaro]]

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

[Sotaro Ikeda [:sotaro]]

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

Comment 12

[Jan Andre Ikenmeyer [:darkspirit]]

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.