Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Build ID: 20190801214227
Affected Firefox versions: Firefox 69 beta 9 and Nightly 70.0a1

Preconditions:
Choose "High Contrast #1" theme from you PC.
Start menu -> Turn on dark mode for apps-> in the Colors section, click on High contrast settings -> Turn ON high contrast and Choose a theme (High Contrast #1)

Steps to reproduce:

1. Launch Firefox with a clean profile
2. Open multiple tabs
3. Click anywhere on your desktop in order to un-focus the Firefox window

Actual results:
When Firefox is unfocused - the tab's title become invisible and so are all the buttons located on the tabs bar (+<>)
Please see the screen-cast for more details.

When High Contrast #2 theme is applied - the tabs and buttons are invisible when the Firefox window is focused.
When High Contrast White theme is applied - the tabs and buttons are invisible when the Firefox window is unfocused.
When High Contrast Black theme is applied - the tabs and buttons are properly displayed.

Expected results:
The tabs are dark, the favicons, titles and buttons are visible.

Regression range:
It seems that Bug 1524284 is the culprit here:
changeset: 7998879d67133172b899cc84e5925ea07c7854fa
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e39bd319fe3e2d8e310467fa65bc2a8eab398992&tochange=7998879d67133172b899cc84e5925ea07c7854fa

Jeff, could you please take a look over this?

Win10 1903/GTX1060
This behavior is not restricted to Intel. It's already shipped to Nvidia and AMD users.

Basic: unaffected
D3D11 + D3D11 (Advanced Layers): Fixed by gfx.direct3d11.use-double-buffering;false (only enabled on Nightly so far: bug 1547775)
WebRender: Fixed by gfx.webrender.dcomp-win.enabled;false.

It's only a problem with Default theme. Should this be moved to Firefox :: Theme?

The problem seemed to be caused by CompositorWindow usage. It is necessary for DirectComposition usage and DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL swap chain. CompositorWindow might be used only on Windows10.

When a high contrast theme is activated, native theme is used than Lightweight Theme. In this case, TabsInTitlebar is rendered as transparent. It seems to expect that window color appear as the background color. But when CompositorWindow is used, rendered as transparent does not work as showing correct background color.

https://searchfox.org/mozilla-central/source/browser/themes/windows/browser-aero.css#94

There seems to be 2 ways to address the problem.

• [1] Make rendering as transparent at CompositorWindow work for native theme's background
• [2] Do not use transparent as TabsInTitlebar background color.

I looked into [1], but I could not find a way to do it.
[2] seems possible. But I am not sure, if we could do it without regression.

Moving over to Firefox::Theme to ask for a theme-side fix.

Only Default theme adapts to Windows' high contrast mode. It needs a tweak because Firefox' window is not transparent on Win10 (comment 3 + bug 1564514 comment 10).
Could you detect high contrast mode and set correct tab bar background colors (e.g. blue/turquoise) or find a different solution?

Activate High Contrast Mode, set these prefs and restart Nightly to compare previous and current appearance:

Dao, comment 4 something we can do?

I think we could explicitly set ActiveCaption and InactiveCaption as background colors.

The top border doesn't have the right thickness and more crucially it doesn't connect with the native side borders ... I don't think we can fix this properly in the theme.

This is the patch that I used for the screenshot.

I'm moving this back to Graphics to reevaluate whether this can be fixed there.

Sotaro, do you think it is worth trying option 2 that you mentioned in comment 3? https://bugzilla.mozilla.org/show_bug.cgi?id=1570879#c3

(In reply to Jessie [:jbonisteel] plz needinfo from comment #11)

Sotaro, do you think it is worth trying option 2 that you mentioned in comment 3? https://bugzilla.mozilla.org/show_bug.cgi?id=1570879#c3

Option 2 is what my patch tried. I think we need to reassess option 1.

[Tracking Requested - why for this release]:

Major accessibility regression for High Contrast mode users with Intel GPUs. That we already shipped this to AMD and Nvidia users should be no excuse, and Intel hardware might very well be more prevalent among High Contrast mode users. (We're generally talking about a small population here, but again if we take accessibility seriously this should be no excuse.)

We can still potentially fix this in beta 70 but time is fairly short.

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

(In reply to Liz Henry (:lizzard) from comment #13)

We can still potentially fix this in beta 70 but time is fairly short.

One option would be to take my suboptimal patch as a stopgap for 70 while figuring out how to properly handle this long-term.

I looked into option [1], but I still could not find out a cause of the problem: ( Chromium also uses child window in GPU process and uses transparency during high contrast mode. And chrome browser showed the high contrast background correctly.

• DesktopNativeWidgetAura::UpdateWindowTransparency()
• https://cs.chromium.org/chromium/src/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc?l=441
• BrowserDesktopWindowTreeHostWin::GetClientAreaInsets()
• https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc?l=157

How to handle child window in GPU process is same between chromium and Firefox. Then a difference seemed to exist around parent window.

I tested for changing a content area size(child window size) of window. Then, when content size was as same as windows size and with DXGI_ALPHA_MODE_PREMULTIPLIED swap chain, I saw that tab area was rendered by high contrast background. It is not a solution of the problem, but it might be a hint of why high contrast background is not rendered with child window on Firefox.

From investigation, the followings are necessary to address the problem.

• Clear parent window by transparent black.
• Use SwapChain with DXGI_ALPHA_MODE_PREMULTIPLIED for child window in GPU process.

SwapChain with DXGI_ALPHA_MODE_PREMULTIPLIED could cause performance regression. Then we need to use it only when necessary. When SwapChain switches between DXGI_ALPHA_MODE_IGNORE and DXGI_ALPHA_MODE_PREMULTIPLIED, the SwapChain needs to be re-created. In "Direct3D 11 (Advanced Layers)" or "CompositorD3D11" cases, it seems better just to disabled double buffering(DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL usage).

On Firefox 70, the double buffering at SwapChain is not enabled with "Direct3D 11 (Advanced Layers)" or "CompositorD3D11". Then it could be handle as a different bug. Though, Bug 1580222 made "double buffering ride the trains" from Firefox 71.

The patch is wip.
It addressed the problem for simple use case. But the SwapChain re-creation is not implemented yet. And sometime parent window was not cleared by transparent black. We needs to add an invalidation.

Bug 1586555 is created for Comment 17.

https://hg.mozilla.org/mozilla-central/rev/cdf7aba0ad00

Is this intended for uplift to 70? Or can it ride the trains with 71?

Comment on attachment 9099143 [details]
Bug 1570879 - Fix high contrast theme handling with DirectComposition and WebRender

Beta/Release Uplift Approval Request

• User impact if declined: Tab bar is broken when using a high contrast theme.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It does not change how rendering is done during non-high contrast theme. And the added transparency handling codes are relatively simple.
• String changes made/needed: none

Comment on attachment 9099143 [details]
Bug 1570879 - Fix high contrast theme handling with DirectComposition and WebRender

Fix for high contrast theme issue with WebRender, important for a11y
OK for beta 14 uplift.

I am going to create a patch for beta.

Update a comment a bit.

https://hg.mozilla.org/releases/mozilla-beta/rev/3617fc291cc4

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0 (Build ID: 20191009213914)

I can confirm that on the default settings and High Contrast themes active, the tab bar is no longer broken when WebRender is enabled. Verified on Windows 10 x64 (with Intel(R) HD Graphics 530).

I also verified the appearance of the Tabs bar with the modified preferences mentioned in Comment 4, and I found one situation in which the issue is still reproducible: - D3D11 + double buffering (Nightly-only so far) when gfx.webrender.force-disabled;true.

Sotaro, could you please tell me if this is expected?

(In reply to Simona Badau from comment #31)

I also verified the appearance of the Tabs bar with the modified preferences mentioned in Comment 4, and I found one situation in which the issue is still reproducible: - D3D11 + double buffering (Nightly-only so far) when gfx.webrender.force-disabled;true.

Sotaro, could you please tell me if this is expected?

It is Bug 1586555 .

(In reply to Sotaro Ikeda [:sotaro] from comment #32)

(In reply to Simona Badau from comment #31)

I also verified the appearance of the Tabs bar with the modified preferences mentioned in Comment 4, and I found one situation in which the issue is still reproducible: - D3D11 + double buffering (Nightly-only so far) when gfx.webrender.force-disabled;true.

Sotaro, could you please tell me if this is expected?

It is Bug 1586555 .

Thanks, Sotaro! Considering bug 1586555 tracks the issue mentioned in Comment 31, marking this as verified on the latest Nightly 71.0a1.

Verified as fixed also on Firefox 70 beta 14 - tested on Windows 10 x64 (with Intel(R) HD Graphics 530).