User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Using Firefox on any Linux based OS and enabling dark mode

Actual results:

Firefox doesn't switch to the dark mode

Expected results:

Firefox should follow that preference. That can be done using the recently standardized org.freedesktop.appearance.color-scheme key.
Here's some reference:
https://github.com/flatpak/xdg-desktop-portal/pull/633/
https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/12
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/49
To test your implementation use:
https://gitlab.gnome.org/exalm/color-scheme-simulator

Setting a component for this enhancement in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

In which distro are you seeing firefox not switching correctly to dark mode?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

In which distro are you seeing firefox not switching correctly to dark mode?

elementary OS is an example. But this issue is gonna be a lot more common since GNOME adopted the freedesktop colorscheme preference instead of dark GTK themes for the next version. KDE Plasma has a PR to adopt this as well.

So GtkSettings has gtk-application-prefer-dark-theme which we read and respect / react to changes. Ideally GTK would just work in that regard?

Do you know if applications are expected to set that in response to the portal setting or if that's supposed to just work?

(Or if that's just deprecated / somehow superseded by the portal stuff)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

(Or if that's just deprecated / somehow superseded by the portal stuff)

Yep. GTK doesn't set the dark mode anymore. The platform specific libraries (such as libhandy, libadwaita, granite etc.) do that.

Seems to work nicely on my machine :-)

https://treeherder.mozilla.org/jobs?repo=try&revision=43bffdc65265dcff0af26c6f8329f684603d2b6c should have builds for testing in a while.

First time dealing with dbus and so on, so better ways of doing things or other feedback appreciated!

Nice work! Been wanting this implemented for a while now.

Tested on GNOME and works with the new xdg-desktop-portal setting, thanks!.

Regarding the patch itself, there is a minor nit in the comment

# Whether to try to use gtk portal for the setting
# https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Settings
#  - 0: never
#  - 1: always
#  - 2: auto
- name: widget.use-xdg-desktop-portal.settings
  type: int32_t
  value: 2
  mirror: always

this is a xdg-desktop-portal setting, it is not related to gtk itself.

Another thing to have in mind is that setting dark mode via gnome-tweaks has a higher priority over the xdg-desktop-portal setting. I don't know if this should be the case given that gtk-theme-name and gtk-application-prefer-dark-theme are unsupported methods to set a global dark mode.

(In reply to Maximiliano from comment #11)

Tested on GNOME and works with the new xdg-desktop-portal setting, thanks!.

Great, thanks for testing! I tried to test on gnome 42 but the VM didn't start up so tested with elementary instead.

this is a xdg-desktop-portal setting, it is not related to gtk itself.

Fair enough, will fix before landing.

Another thing to have in mind is that setting dark mode via gnome-tweaks has a higher priority over the xdg-desktop-portal setting. I don't know if this should be the case given that gtk-theme-name and gtk-application-prefer-dark-theme are unsupported methods to set a global dark mode.

That presumably changes the gtk-theme-name to something like "Adwaita-dark" or something? If so yeah that's expected. We don't mess with the GTK theme name to compute the system theme, so if it's dark it's dark.

https://hg.mozilla.org/mozilla-central/rev/8892a1438ad7

cf. https://phabricator.services.mozilla.com/D135768#4433217

Replied there.

I've been trying to test the new color-scheme settings on KDE (using KDE Neon unstable edition) with the color-scheme pref added (Plasma 5.24)

Steps:

1. Install KDE Neon Unstable in KVM and update'
2. Check qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read "org.freedesktop.appearance" "color-scheme" for the correct color-scheme detection.
3. Download Nightly with the freedesktop color-scheme settings added.
4. Run Nightly with a new, unmodified profile. Make sue the System Theme Auto is default
5. Check https://codepen.io/kleinfreund/full/NmpKZM to make sure prefers-color-scheme is detected.
6. The default with KDE is Breeze Light and Nightly OTB follows this..
7. In KDE settings change from light theme to dark theme.
8. Check qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read "org.freedesktop.appearance" "color-scheme" for the correct color-scheme detection.
9. Observer the System theme change to Dark
10. Apart from the toolbars, Nightly does not change and remains Light
11. Restart Nightly. Nightly remains Light
    12 Check https://codepen.io/kleinfreund/full/NmpKZM Nightly still says Light.

All of the xdg prefs are on 2

Perhaps I'm misunderstanding but I thought this new setting was supposed to make Firefox follow the system theme?

(In reply to Pulse from comment #17)

1. Install KDE Neon Unstable in KVM and update'

Curious if you have ready steps for this somewhere, I could dig a bit more if so.

Perhaps I'm misunderstanding but I thought this new setting was supposed to make Firefox follow the system theme?

It sounds like the breeze theme in KDE doesn't support color-switching via gtk-application-prefers-dark-theme, which is what we use. If that's the case that seems like a bug to fix there rather than in Firefox. IIRC, KDE will stash a bunch of colors and settings in ~/config/gtk-3.0 which will keep the light / dark theme. We could try to be more aggressive in respecting the user preference, but in this case it'd mean switching to adwaita-dark or so, which is not great and I'd rather avoid.

Ah I guess it's just https://neon.kde.org/download, TIL that has its own distro.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #19)

Ah I guess it's just https://neon.kde.org/download, TIL that has its own distro.

They do. It;s just their testing distro. The unstable version gets all the latest updates first hence the reason for using it in this test.

KDE has implemented support for the freedesktop color-scheme - See That has been merged into Plasma 5.24. coming February 8th but the aforementioned Neon has it already.

Sure. Actually I have it here on my plasma install (I'm on Fedora Rawhide). Any theme other than Breeze like Adwaita or Arc seems to react to the setting just fine, so I'm moderately sure this is a bug in either the breeze theme or kde-gtk-config.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #21)

Sure. Actually I have it here on my plasma install (I'm on Fedora Rawhide). Any theme other than Breeze like Adwaita or Arc seems to react to the setting just fine, so I'm moderately sure this is a bug in either the breeze theme or kde-gtk-config.

So, how do we find out? I was discussing this with a KDE contributor on reddit and it was there I asked if I should file a bug here.

According to the KDE invent page:

Currently only maps schemes from the breeze family to light/dark and returns no preference for third-party scheme.

(In reply to Pulse from comment #22)

Currently only maps schemes from the breeze family to light/dark and returns no preference for third-party scheme.

This was changed later in https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/52, which actually looks at the colors to determine whether to return dark or light for the FreeDesktop preference.

Well, when I switch light / dark preference, ~/.config/gtk-3.0/colors.css doesn't change at all (keeps the light colors I usually have). Those are the colors the breeze theme later uses, and that file is managed by kde-gtk-config.

This can be fixed in multiple ways and I'm not sure which one is best, the ideal change probably requires changes in both projects. In particular, colors.css would ideally keep both light and dark colors, and breeze-gtk would switch between them from dark.css (this way everything works like in every other GTK theme). But at the very least kde-gtk-config should write the dark colors when switching the preferred appearance to dark, and that'd fix it as well.

But anyways it's clear this is not a Firefox issue because the same issue happens in e.g., gedit.

Actually, I lie, the file I mentioned in comment 24 does change, it seems. However the color-reload-module in kde-gtk-config doesn't prevent the old styles from applying because it imports colors.css from gtk.css as well.

The dynamic change seems to work if I remove ~/.config/gtk-3.0/gtk.css.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)

It sounds like the breeze theme in KDE doesn't support color-switching via gtk-application-prefers-dark-theme, which is what we use. If that's the case that seems like a bug to fix there rather than in Firefox. IIRC, KDE will stash a bunch of colors and settings in ~/config/gtk-3.0 which will keep the light / dark theme. We could try to be more aggressive in respecting the user preference, but in this case it'd mean switching to adwaita-dark or so, which is not great and I'd rather avoid.

FWIW I'm running a non-nightly version (96.0) of Firefox without the FreeDesktop portal support, and here Firefox actually adapts (theme plus CSS prefers-color-scheme) when I change between Breeze Light and Dark, although this needs a restart of Firefox to take effect. If it helps I can attach a screencast showing that.

Actually never mind that, I'm not quite sure off-hand which config changes do trigger the colors.css regeneration. Changing Appearance > Colors definitely does, but switching color scheme does not. Changing Appearance > Colors doesn't apply dynamically because of comment 26, but it applies after a restart.

So anyways there are multiple bugs here but none of them are a Firefox bug afaict.

So, I just downloaded Nightly and at first it does respond to changes in KDE colorscheme live without restart. However, it seems to work inconsistently?

On a completely fresh (nonexistent) profile, the first few switches from dark to light work perfectly. After that changing colors results in a incorrect-looking Firefox (white text on light bg). Restarting fixes it, but further changes again result in an incorrect appearance. Deleting the profile resets everything.

Do you reckon this might be a Breeze-Gtk issue? If I change the Gtk theme to Default (Adwaita), then Firefox no longer responds to any change in colorscheme, even though the Portal DBus command correctly reflects dark/light. This leads me to think maybe Firefox is not using the Portal at all on my system for some reason.

I filed https://bugs.kde.org/show_bug.cgi?id=448877 for the kde-gtk-config bits.

(In reply to Bharadwaj Raju from comment #29)

On a completely fresh (nonexistent) profile, the first few switches from dark to light work perfectly. After that changing colors results in a incorrect-looking Firefox (white text on light bg).

Changing colors where? In the system settings?

Restarting fixes it, but further changes again result in an incorrect appearance. Deleting the profile resets everything.

Do you reckon this might be a Breeze-Gtk issue? If I change the Gtk theme to Default (Adwaita), then Firefox no longer responds to any change in colorscheme, even though the Portal DBus command correctly reflects dark/light. This leads me to think maybe Firefox is not using the Portal at all on my system for some reason.

Can you file a new bug and attach the logs of MOZ_LOG=LookAndFeel:5 /path/to/nightly/firefox when Firefox changes? That should tell whether it's using the dbus setting or not.

Changing colors where? In the system settings?

Yes.

Can you file a new bug and attach the logs of MOZ_LOG=LookAndFeel:5 /path/to/nightly/firefox when Firefox changes? That should tell whether it's using the dbus setting or not.

Done. https://bugzilla.mozilla.org/show_bug.cgi?id=1751403