1703980 - On macOS, tooltips and non-native context menus have white-on-white text in the combination Firefox Dark + macOS Light, if widget.macos.respect-system-appearance is enabled

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[(inactive) Nihanth Subramanya [:nhnt11]]

Attachment: Screen Shot 2021-04-09 at 12.55.01 AM.png

Screenshot attached!

I'm on macOS Catalina 10.15.7, and I've got macOS's dark mode disabled, and Firefox's theme set to Dark. I've tried clearing out all the proton prefs I'd previously set, updating Nightly, etc., and the problem persists. Screenshot attached.

Comment 1

[Markus Stange [:mstange]]

Do you have widget.macos.respect-system-appearance set to true?

Comment 2

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to Markus Stange [:mstange] from comment #1)

Do you have widget.macos.respect-system-appearance set to true?

Huh, I do indeed! I don't remember ever setting that - I wonder if it was from a study or something?

Anyway, setting it to false immediately fixed the issue. Also, FWIW I had widget.macos.native-context-menus=false. Setting THAT to true, along with the other one, resulted in a dark context menu with light text, which looks correct for macOS dark mode. Though as I said, I have macOS dark mode disabled and Firefox dark theme enabled.

Thanks!

Comment 3

[:Gijs (he/him)]

(In reply to Nihanth Subramanya [:nhnt11] from comment #2)

resulted in a dark context menu with light text, which looks correct for macOS dark mode. Though as I said, I have macOS dark mode disabled and Firefox dark theme enabled.

This is pretty weird, because AIUI with those prefs set we're using native APIs to show the context menu, so I don't understand why it would then not obey macOS settings for dark mode. But I can reproduce this...

Something similarly broken also seems to happen to sheets - if in this configuration you go to about:support and click the "Troubleshooting mode..." button (while bug 1685346 is still unfixed), the resulting sheet has a dark background but also dark text (!) which makes it very hard to read. Markus, do you know what's causing this?

Comment 4

[Markus Stange [:mstange]]

This bug also applies to tooltips, which will remain non-native.
Ok, so what happens here is that system colors respect the document's lwtheme, -moz-default-appearance drawing respects the document's lwtheme, but popup widget vibrancy does not follow the document's lwtheme. We only set the "override appearance" on the document's top level widget, not on the popup widgets inside it.
We will need to find a way to set the appearance on popup widgets based on the document's lwtheme. Or maybe a way to obtain the document's top level widget's NSWindow, and use that as the popup NSWindow's appearanceSource.

(In reply to :Gijs (he/him) from comment #3)

(In reply to Nihanth Subramanya [:nhnt11] from comment #2)

resulted in a dark context menu with light text, which looks correct for macOS dark mode. Though as I said, I have macOS dark mode disabled and Firefox dark theme enabled.

This is pretty weird, because AIUI with those prefs set we're using native APIs to show the context menu, so I don't understand why it would then not obey macOS settings for dark mode. But I can reproduce this...

Which macOS version is this on? The AppKit release notes for Big Sur say that you can override the appearance of native context menus starting with Big Sur, and we have code in place to have native context menus get their appearance from the system instead of the parent window. But maybe the inheriting is also happening pre-Big Sur?

Something similarly broken also seems to happen to sheets

This was filed as bug 1704016.

Comment 5

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to Markus Stange [:mstange] from comment #4)

Which macOS version is this on?

I'm on macOS Catalina 10.15.7.

Comment 6

[Markus Stange [:mstange]]

(In reply to Nihanth Subramanya [:nhnt11] from comment #5)

I'm on macOS Catalina 10.15.7.

Thanks, I've filed bug 1704102 for the native context menu issue.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1700294

Comment 8

[Romain Testard [:RT]]

Martin, can you please help set a priority for this one?

Comment 9

[Martin Balfanz [:mbalfanz]]

It's an important issue, marking it as a P2. However, note that work that requires widget.macos.respect-system-appearance set to true (bug 1623686) will be post-mr1.

Comment 10

[Romain Testard [:RT]]

Thanks, Pascal FYI with widget.macos.respect-system-appearance being default off on 89 it sounds like this should not be tracked as a 89 regression?

Comment 11

[Pascal Chevrel:pascalc]

Marking as disabled for 89 since it requires setting a pref to a non-default value.

Comment 13

[Harry Twyford]

This is fixed for me now that bug 1715145 has landed. Please let me know if you can still reproduce the issue.

Comment 14

[Timea Zsoldos [:tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 89.0a1 (2021-04-08) on macOS 10.15
I can confirm this issue is fixed, I verified using Firefox 91.0b4 macOS 10.15, I mention that the pref widget.macos.respect-system-appearance was renamed to widget.macos.support-dark-appearance (see: bug 1715145, comment 3).