1475520 - macOS dark mode should apply to context menus

Status: RESOLVED FIXED

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

Description

[Tim Nguyen :ntim]

Attachment: Screenshot 2018-07-13 at 13.13.24.png

Comment 3

[Florens Verschelde :fvsch]

From my duplicate bug, perhaps related:

> I’m also noticing that Nightly is using a "Light" UI for other parts, such as the application's title bar which appears in fullscreen mode or when ticking "Title Bar" in Customize.

Comment 5

[pshirshov]

Attachment: Screenshot 2019-08-29 at 16.46.23.png

Eh. It's still broken - and that's very annoying.

Comment 6

[pshirshov]

Related:

• bug 1559646 Native titlebar doesn't respect dark mode on Mac
• bug 1561725 Blank page is white under Mac OS dark mode

Comment 8

[emikaadeo]

Hi,
this bug is also present on macOS Catalina official release (10.15 19A583) with Firefox 70 beta14.

Comment 9

[emikaadeo]

Attachment: Zrzut ekranu 2019-10-13 o 10.13.36.png

Comment 10

[emikaadeo]

Attachment: Zrzut ekranu 2019-10-13 o 10.12.50.png

Comment 11

[emikaadeo]

Attachment: Zrzut ekranu 2019-10-13 o 10.13.36.png

Comment 12

[emikaadeo]

Attachment: Dialog box

This bug apply not only to context menus but also for dialog boxes like "Save page as", "Open file" etc. which also should be dark but remains light.
Other browsers like Safari or Chromium based browsers already have complete dark mode support.
It would be nice to have this also in Firefox.

Comment 13

[emikaadeo]

Do you guys know if there's any progress with this bug?

Comment 14

[Tim Nguyen :ntim]

(In reply to emikaadeo from comment #13)

Do you guys know if there's any progress with this bug?

https://bugzilla.mozilla.org/show_bug.cgi?id=mojave-sdk will probably help here, it's probably not going to get fixed any time soon however.

Comment 15

[cniff]

Attachment: Screenshot 2019-11-20 at 00.47.34 2.png

Seems this issue is getting worse. All popups in Firefox 70.0.1 still have bright background, but now they also have white text.

Comment 16

[pshirshov]

Oh, come on, who cares about UX. They are working on really important things like "Ad Privacy Info dialog for sponsored Top Sites tiles."

Comment 17

[cniff]

Am I missing something, why isn't there at least a workaround incorporated into Firefox yet? Since a real fix does not seem to appear that soon, it would just make sense to disable macOS dark mode on app start:

- (void)applicationDidFinishLaunching:(NSNotification*)notification {

    // prevent macOS dark mode for this app (since not supported by Firefox)
    if (@available(macOS 10.14, *))
        NSApp.appearance = [NSAppearance appearanceNamed:NSAppearanceNameAqua];

    ...
}

If the required macOS 10.14 SDK is not available on the build server, then you can still call this setter by calling the fundamental Objective-C C-function objc_msgSend() and passing the respective setter as string and value as raw argument.

Comment 18

[Tim Nguyen :ntim]

(In reply to cniff from comment #17)

Am I missing something, why isn't there at least a workaround incorporated into Firefox yet?

Are you building your own version of Firefox ? If so, this is a known issue when building with the 10.14 SDK (see bug 1578917). Official Firefox builds don't have this issue since they build with the 10.11 SDK.

Since a real fix does not seem to appear that soon, it would just make sense to disable macOS dark mode on app start:

If you have a proper fix in hand, feel free to submit a patch and we'll gladly accept it :) Building with the 10.14/15 SDK is something we want to do eventually.

Comment 19

[cniff]

(In reply to Tim Nguyen :ntim from comment #18)

Are you building your own version of Firefox ? If so, this is a known issue when building with the 10.14 SDK (see bug 1578917). Official Firefox builds don't have this issue since they build with the 10.11 SDK.

No, that screen shot was taken with official Firefox 70.0.1 build (not a self rolled Firefox binary), running on macOS Mojave 10.14.6 with macOS dark mode enabled.

If you have a proper fix in hand, feel free to submit a patch and we'll gladly accept it :) Building with the 10.14/15 SDK is something we want to do eventually.

I thought I did with my previous comment... kind of. ;-)

Comment 20

[Tim Nguyen :ntim]

(In reply to cniff from comment #19)

(In reply to Tim Nguyen :ntim from comment #18)

Are you building your own version of Firefox ? If so, this is a known issue when building with the 10.14 SDK (see bug 1578917). Official Firefox builds don't have this issue since they build with the 10.11 SDK.

No, that screen shot was taken with official Firefox 70.0.1 build (not a self rolled Firefox binary), running on macOS Mojave 10.14.6 with macOS dark mode enabled.

Interesting, this doesn't happen on my side. Do you mind filing a new bug with information from about:support ? Thanks :)

Comment 21

[cniff]

Well, where are your about:support information? I don't see them anywhere in this report.

Comment 22

[Tim Nguyen :ntim]

(In reply to cniff from comment #21)

Well, where are your about:support information? I don't see them anywhere in this report.

No one has reported your issue (the white text) so far, but the context menu having a light background in dark mode has been known for a while. I'm just trying to get your issue fixed quicker by figuring out where it's from, where about:support information can be handy. If you don't want to share it that's fine, but it'll be slower to figure things out for us. You can alternatively answer these questions: what macOS version are you using? do you have any special config enabled (webrender, etc.) ?

Comment 23

[cniff]

Like I said, macOS Mojave 10.14.6, macOS dark mode enabled, official Firefox 70.0.1 build, no Firefox plugins, nothing special.

Actually its even worse than I thought. Even when I locally disable dark mode for Firefox, that is:
defaults write org.mozilla.firefox NSRequiresAquaSystemAppearance -bool Yes

then Firefox popups are back to normal, BUT the standard CSS text color is now (still) bright white. Consequence: many websites are unreadable unless I disable macOS dark mode for the entire system.

Having said that, I start to wonder whether that's an issue introduced by latest macOS update.

Which precise macOS version are you running on there?

Comment 24

[Albert Scheiner [:alberts]]

Attachment: image.png

Hey cniff, I just updated my stable to 70.0.1 as well (mainly using Nightly) and also can't reproduce the issue. Will keep an eye out and update here in case this changes.

Comment 25

[cniff]

Since you can't reproduce it, what's your precise macOS build number? Mine is 18G1012 (which is a security update from Oct 31st 2019). You get the build number by clicking on the version number triple from the "About This Mac" dialog.

Comment 26

[Albert Scheiner [:alberts]]

(In reply to cniff from comment #25)

Since you can't reproduce it, what's your precise macOS build number? Mine is 18G1012 (which is a security update from Oct 31st 2019). You get the build number by clicking on the version number triple from the "About This Mac" dialog.

It's the same as yours, "18G1012". Firefox Build ID 20191030021342

Comment 27

[cniff]

Ok, after checking all kinds of settings, both in Firefox as well as on macOS level, I got this issue resolved on my side with:

defaults delete -g NSRequiresAquaSystemAppearance

after rebooting Firefox finally behaves as expected with Dark Mode enabled on macOS.

Looks like this global defaults override was a left over on my installation from early Dark Mode times on macOS, where many apps still had plenty of issues running with Dark Mode. Sorry for the noise!

In case other macOS users come up encountering the same problem, you may consider checking for this global defaults key on Firefox startup and suggest users to remove it. Because if that combination of a) global defaults key and b) Dark Mode enabled exists, then Firefox is almost unusable (e.g. standard forms are white on white, standard CSS text color is inverted, etc.). But maybe I remain the only one ... ;-)

Comment 28

[emikaadeo]

(In reply to emikaadeo from comment #12)

Created attachment 9100735 [details]
Dialog box

This bug apply not only to context menus but also for dialog boxes like "Save page as", "Open file" etc. which also should be dark but remains light.
Other browsers like Safari or Chromium based browsers already have complete dark mode support.
It would be nice to have this also in Firefox.

72.0beta2 landed, problem still exist because it's still build on old 10.11 SDK. I'm guessing that 72.0 will be another Firefox release with unproper dark mode handling.

Comment 29

[Stephen A Pohl [:spohl]]

This should get addressed with bug 1623686.

Comment 30

[yuyang97]

How is it still not getting fixed....

By the way it is not just context menus. It is every system popups. Including dictionary (when you force click on a word) and other language input windows (say Chinese, when you type in a word you get a window to chose what character gets typed out) and none of them are in dark mode.... Neither Chrome or Safari have this issue. Really sad to see it still isn't fixed after such a long time

Comment 31

[Alwyn Edison Mendonca]

https://www.reddit.com/r/firefox/comments/gug8xg/macos_theming_not_consistent/

Comment 32

[Maksym Fedoriaka]

Still an issue for me, MBP 16 inch, Catalina 10.15.6, Firefox 78.0.2 (64-bit)

Comment 33

[phlogi]

(In reply to cniff from comment #27)

Ok, after checking all kinds of settings, both in Firefox as well as on macOS level, I got this issue resolved on my side with:

defaults delete -g NSRequiresAquaSystemAppearance

after rebooting Firefox finally behaves as expected with Dark Mode enabled on macOS.

Looks like this global defaults override was a left over on my installation from early Dark Mode times on macOS, where many apps still had plenty of issues running with Dark Mode. Sorry for the noise!

In case other macOS users come up encountering the same problem, you may consider checking for this global defaults key on Firefox startup and suggest users to remove it. Because if that combination of a) global defaults key and b) Dark Mode enabled exists, then Firefox is almost unusable (e.g. standard forms are white on white, standard CSS text color is inverted, etc.). But maybe I remain the only one ... ;-)

@cniff: I do not have this option set globally, nor for the firefox /mozilla products:

The domain/default pair of (mozilla.thunderbird, NSRequiresAquaSystemAppearance) does not exist
The domain/default pair of (kCFPreferencesAnyApplication, NSRequiresAquaSystemAppearance) does not exist

The context menus as well as open/save file dialogs are all white in Firefox and Thunderbird.
Any idea what to check?

Comment 34

[cniff]

(In reply to phlogi from comment #33)

@cniff: I do not have this option set globally, nor for the firefox /mozilla products:

The domain/default pair of (mozilla.thunderbird, NSRequiresAquaSystemAppearance) does not exist
The domain/default pair of (kCFPreferencesAnyApplication, NSRequiresAquaSystemAppearance) does not exist

The context menus as well as open/save file dialogs are all white in Firefox and Thunderbird.
Any idea what to check?

You got me wrong. I deleted the global NSRequiresAquaSystemAppearance entry, however I still need the local NSRequiresAquaSystemAppearance entry for the Firefox app:

defaults write org.mozilla.firefox NSRequiresAquaSystemAppearance -bool Yes
By setting NSRequiresAquaSystemAppearance Yes this actually means "this app does not work in Dark Mode" and macOS will show that specific app (i.e. Firefox in this case) in classic, bright mode.

The problem in my case with the global entry was, that for some reason, the entry used an incorrect data type (not Bool), and that in turn caused macOS to misbehave and sticking to dark mode, even though I had the local entry NSRequiresAquaSystemAppearance YES enabled for Firefox. Probably a macOS bug, because the local entry should still have precedence, no matter what you set as global entry.

Comment 35

[phlogi]

Oh I see, thanks for the clarification. In the meantime I realized that other bugs are still pending and i we just have to wait for full darkmode support.

Comment 36

[emikaadeo]

According to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1700679
Is that means that we will have to wait for Firefox 90 to get proper darkmode? Even when such a big interface update (Proton) coming with Firefox 89 ?

Comment 37

[matthias koplenig [:metasieben]]

There is an uplift-request in comment 7 of bug 1700679, meaning it should/will be released with Fx89.

Comment 38

[eboyee]

FF89.0b12 it's finally working!!

Comment 39

[Markus Stange [:mstange]]

This was fixed in 89 by bug 1702351, bug 34572, bug 1702100 and bug 1704102.