1734367 - Windows native appearance for <menulist> elements conflicts with dark mode dialogs, makes text illegible

Status: VERIFIED FIXED

(Core :: Widget, defect)

Description

[Shane Hughes [:aminomancer]]

Attachment: The menulist inherits white text color via -moz-dialogtext, but still has a white background. Because of the appearance property I think

Steps:

• Open any native dialog (i.e. not attached to a chrome window) that has a <menulist> element.

Expected:

• Menulist would have dark background, light text; or light background, black text.

Actual:

• Menulist has white text due to -moz-dialogtext and has the very light gray background innate to menulist & select elements with native appearance.

I also think, while we are applying dark styles to dialogs, the checkboxes and radio buttons should be adjusted to be more in line with their in-content counterparts. In about:preferences you can see the unchecked state for these elements has a very dark background and a slightly lighter border. The checked state uses a cyan "accent" background color which is bright enough the checkmark/dot can be black.

And <button> elements could be given a background color, border-radius, and no border, to achieve the same consistency. Should dialogs just load common.css? Well, basically if the background is gonna be dark inside these dialogs now, I think basically all basic xul elements have to be given non-native styles, right?

I'm sure there are other problematic elements too, it's just hard to stumble upon a dialog that has them. But if you open a dialog and just start creating xul elements at random, I think you'll find other issues. I will experiment with some other components and post back on here if I find another element that's too bright.

Comment 1

[Shane Hughes [:aminomancer]]

I think these dialogs load common.css when you attach them to a window or browser. And I think that's why they look consistent with the in-content styles. Idk if there are other functional considerations but it seems like if Firefox is gonna style these dialogs according to user color scheme, it might as well make them look basically the same as their modal counterparts.

Like if you open the "add bookmark" dialog from within a chrome window, you get the attached/modal version. But if you hit "add bookmark" menuitem in the context menu from within a bookmarks manager window (places.xhtml), you get a native version of the exact same dialog. I think with gtk they already look much more similar to equivalent modal dialogs. At least I've seen pictures to that effect.

By the way, the "page info" dialog looks really funny, I think due to the large number of trees or richlistboxes. That's the ctrl + i hotkey

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1734367 - Teach windows to draw dark widgets using the non-native theme. r=mstange!,#desktop-theme-reviewers!

This should be more flexible / less footgunny, always ensuring there's enough
contrast. If the front-end wants to override the non-native appearance they can
still do it using appearance: none of course.

This reverts my other CSS fixes for Windows dark mode for buttons / textfields,
as those are supported by nnt.

Patch incoming for Linux in bug 1733968, as Linux has a similar issue when it
can't draw mismatched widgets with the system theme (and we can fix it now).

I intentionally didn't override GetWidget{Padding,Border}, as to avoid changing
sizing unnecessarily (the non-native-theme is flexible enough to support
basically whatever size you throw at it, so it doesn't matter).

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I don't have a strong opinion about whether these should use in-content styles, but ^ should fix virtually all the contrast issues while allowing the front-end to override them as they want.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0538ee85cbed
Teach windows to draw dark widgets using the non-native theme. r=mstange,desktop-theme-reviewers,dao

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/0538ee85cbed

Comment 8

[Mathew Hodson]

I don't think Firefox 94 is affected. Nightly 94.0a1 build 20211004095342 uses a light mode dialog and there isn't a contrast issue.

Last good revision: 1ff04e10cd2318b494c0f05777cd80291289d127
First bad revision: d39b23efefe7e7d89d8dfd0ba188ad6af2b0a9ed
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ff04e10cd2318b494c0f05777cd80291289d127&tochange=d39b23efefe7e7d89d8dfd0ba188ad6af2b0a9ed

Regressed by bug 1733569

Comment 10

[Anca Soncutean, Desktop QA]

Reproduced with Fx 95.0a1 (2021-10-05) on Windows 10.
Verified fixed with Fx 96.0a1 (2021-11-04) and Fx 95.0b2 on Windows 10 and macOS 12.