1715990 - When HCM is enabled and with the non-dark default Firefox theme, 2 caption buttons are painted on top of each other

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Itiel]

Attachment: Screenshot

STR:

1. Using Windows 10, New Firefox profile, default theme is selected, Windows' theme is NOT dark
2. Enable HCM
3. See the caption buttons -- there's 1 set of the Firefox ones on top of the (disabled) HCM ones. See attached.

Note that setting intl.l10n.pseudo to bidi will make this more obvious -- with that, the entire captions are visible on the other side.

Comment 1

[Itiel]

Attachment: Screenshot 2

This is how it looks like when installing the unlocalized version of Firefox, and the installing the Hebrew langpack on top of it.
This is how it normally looks like, without touching any prefs.

See also bug 1714965.

Comment 2

[Itiel]

Bisecting with mozregression, I got to this range 2019-10-08 to 2019-10-07:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4651f71eeb5476a6dc9002a47a45c3a5b17aba6c&tochange=e1a65223d498aa0b8e3e4802d8267db2768073d9
Bug 1570879 is the most likely regressor, but otoh in the "Good" state the entire title bar is always black, whereas in the bad state it's purple-ish. So I'm not sure if bug 1570879 made the bug apparent, or if it actually regressed it.

sotaro, wdyt?

Comment 3

[Sotaro Ikeda [:sotaro]]

(In reply to Itiel from comment #2)

Bug 1570879 is the most likely regressor, but otoh in the "Good" state the entire title bar is always black, whereas in the bad state it's purple-ish. So I'm not sure if bug 1570879 made the bug apparent, or if it actually regressed it.

It seemed that bug 1570879 made the bug apparent. Before the fix, high contrast mode did not work as expected when compositor window was used. With the following command, "2 caption buttons" problem seems to exist longer time.

./mach mozregression --good 2019-06-12 --pref gfx.webrender.force-disabled:true gfx.direct3d11.use-double-buffering:false intl.l10n.pseudo:bidi

Comment 4

[Sotaro Ikeda [:sotaro]]

2 caption buttons are painted on top of each other

One caption button was rendered by DWM during HCM by DWMNCRP_USEWINDOWSTYLE

• https://searchfox.org/mozilla-central/rev/294f10eff7398d6b05beac6aa256d86ac3cb7113/widget/windows/nsWindow.cpp#3369

Comment 5

[Sotaro Ikeda [:sotaro]]

(In reply to Itiel from comment #1)

Created attachment 9226533 [details]
Screenshot 2

This is how it looks like when installing the unlocalized version of Firefox, and the installing the Hebrew langpack on top of it.
This is how it normally looks like, without touching any prefs.

See also bug 1714965.

It seems to related how nsWindows::mIsRTL is initialized. It is initialized only in nsWindow::Create()

• https://searchfox.org/mozilla-central/rev/294f10eff7398d6b05beac6aa256d86ac3cb7113/widget/windows/nsWindow.cpp#882
• https://searchfox.org/mozilla-central/rev/294f10eff7398d6b05beac6aa256d86ac3cb7113/widget/windows/nsWindow.cpp#1014

Comment 6

[Sotaro Ikeda [:sotaro]]

Attachment: temporal patch - Remove min/max button rendered by system

By changing window style, min/max button by system could be removed. But I am not sure a way to remove close button.

Comment 7

[Sotaro Ikeda [:sotaro]]

(In reply to Itiel from comment #1)

Created attachment 9226533 [details]
Screenshot 2

This is how it looks like when installing the unlocalized version of Firefox, and the installing the Hebrew langpack on top of it.
This is how it normally looks like, without touching any prefs.

I confirmed the problem. It seems that local of the langpack is applied after first window is created. Then if I opened a second window, the problem did not happen.

Comment 8

[Sotaro Ikeda [:sotaro]]

Attachment: temporal patch - Add log around LocaleService

Comment 9

[Sotaro Ikeda [:sotaro]]

With Attachment 9227639 [details] [diff], I checked how problem happened. LocaleService::SetAvailableLocales() was called after first window was created. nsWindows::mIsRTL is already initialized in nsWindow::Create(), then nsWindows::mIsRTL could not be initialized correctly.

Comment 10

[Sotaro Ikeda [:sotaro]]

(In reply to Itiel from comment #1)

Created attachment 9226533 [details]
Screenshot 2

This is how it looks like when installing the unlocalized version of Firefox, and the installing the Hebrew langpack on top of it.
This is how it normally looks like, without touching any prefs.

See also bug 1714965.

If nsWindows::mIsRTL is dynamic, we could decrease the problem.

Comment 11

[Sotaro Ikeda [:sotaro]]

Created Bug 1717182 for comment 10.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

So I took a look at this and I can see the same with a few CSS tweaks with the default theme on Windows 10.

The issue is that we're using the -moz-win-exclude-glass / background-color: transparent codepath here on Windows 10 (which I'm not sure is generally expected/supported), so the root background is transparent and we're seeing the titlebar drawn by the compositor.

The windows high contrast mode caption is trivial enough to paint ourselves though, which would fix this.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1715990 - On windows HCM, draw titlebar ourselves rather than relying on the OS. r=#desktop-theme-reviewers

This prevents issues on win10 where this codepath is not really well tested,
and also should be faster.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b74995b8a309
On windows HCM, draw titlebar ourselves rather than relying on the OS. r=desktop-theme-reviewers,dao

Comment 16

[Noemi Erli[:noemi_erli]]

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