The upstream issue in Chromium has been fixed today, at long last. They have implemented a new DarkModeManagerLinux view that monitors the FreeDesktop settings portal, and falls back to GTK/QT theme monitoring for systems where the portal is not supported. As far as I can see, this means that the current workaround for GTK themes in the nativeTheme API of Electron is no longer needed.

@q234rty is correct. Chromium 114 did fix the prefers-color-scheme query for newer distros that implement the XDG Settings portal. You can test it yourself by using a suitable desktop environment (e.g. Fedora 38 / GNOME 44), downloading the latest Chrome/Chromium, opening this site, and toggling the dark mode setting in the desktop environment’s settings. The style of the page should change immediately.

However, since Electron 25 still uses the aforementioned workaround, which is designed for older Linux distributions and older Chromium, the nativeTheme API cannot possibly work as expected for newer systems that rely solely on the Settings portal, since Electron overrides Chromium’s (now correct) current behaviour.

Reproduction steps

I have updated the reproduction repository example by @aeschli.

Prerequisities: use Fedora 38 / GNOME 44

1. Clone the repository, install and start the app

git clone https://github.com/Igetin/electron-25-prefers-color-scheme-test
cd electron-25-prefers-color-scheme-test
npm install
npm start

1. An Electron window should open
2. Switch between the light/dark preference in the OS
   • you can do this in the quick settings panel of the top bar by toggling the “Dark Style” setting

What should happen

• When the light preference is active:
  • The window will have black text on a white background
  • shouldUseDarkColors: false will be printed in the terminal
• When the dark preference is active:
  • The window will have white text on a black background
  • shouldUseDarkColors: true will be printed in the terminal

What actually happens

The window has black text on a white background at all times, and does not respond to the system’s preference. Only shouldUseDarkColors: false is printed to the terminal.

Here’s also an example screenshot of the erroneous behaviour. As can be seen, the dark preference is enabled in the Fedora 38 system, but the Electron window does not reflect this.

Fix

To fix this, Electron must remove the previously mentioned workaround. Chromium now handles the prefers-color-scheme media query in a backwards-compatible manner, which means that it should work for both older distros/apps (that rely on the selected GTK/Qt theme) and newer distros/apps (that rely on the XDG Settings portal preference). Electron no longer needs to provide special handling for Linux distros in the nativeTheme API.

In this context, “old distros” are basically any distros that still rely on GTK themes for light/dark preference. This includes GNOME 41 or older (example: Ubuntu 18.04) and all currently supported Plasma releases (example: Kubuntu 22.04).

GNOME implemented the XDG Settings portal in GNOME 42 . Distros that have 42 or a newer version are “new distros” in this context (examples: Fedora 36+, Ubuntu 22.04).

(Note: KDE technically implemented the XDG Settings portal in Plasma 5.24. However, if you toggle between light and dark appearance in the system settings, it currently still changes the GTK theme under the hood.)

@codebytere Can you please reopen the issue, as this is still unresolved and reproducible on the latest Electron? This was inadvertently closed as a duplicate a few months ago. You marked 36040 as a duplicate of this issue (33635), so this issue should have stayed open as it is the earliest report of the problem.

Same issue on Fedora 37 beta with Gnome 43.

@codebytere Can this issue be reopened?

I tested on Fedora Linux 38 (Workstation Edition), Gnome 44.3, Wayland Electron 26.1.0, Node.js 18.16.1, Chromium 116.0.5845.97

• git clone https://github.com/aeschli/electron-theme-test.git
• cd electron-theme-test, npm i && npm start
• a simple electron window opens

Expected:

• the console prints shouldUseDarkColors: false when the OS uses a light color scheme, or shouldUseDarkColors: true if the OS color scheme is dark

Actual:

• Always shouldUseDarkColors: false, is printed, even when the OS color scheme is dark.

• In the OS settings, switch between light and dark while the window is still open

Expected:

• the console prints a message matching the need OS color scheme

Actual:

• nothing printed

Test running under Wayland:

• cd electron-theme-test, npm i && npm start-wayland

Same problem.

This ticket was actually filed by a Google developer. Freedesktop color-scheme is a recent addition, so it’s not that surprising that developers are not aware of it.
It is nice to see an interest from a Chromium developer in improving the situation of dark mode control for Linux users. Maybe there’s hope.

There is now an unified way to get the current dark mode in Linux by querying or watching with DBus org.freedesktop.appearance color-scheme. Works in both latest KDE and Gnome 42+. You can check it out with

qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read org.freedesktop.appearance color-scheme

Dark mode in Gnome 42+ can be set with Settings -> Appearance -> Style. In KDE 5.24+ it takes effect when you change the UI colors from Settings -> Appearance -> Colors.

Some links about it: About Gnome implementation: https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/ The setting in xdg-desktop-portal: https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.Settings.xml Firefox already supports it: https://bugzilla.mozilla.org/show_bug.cgi?id=1734934

Here are the possible values:

Combining with #33635

This issue is #33635. Was this one closed by accident?

@codebytere I believe you closed this issue by accident. Please reopen it

Combining with #33635

This issue is #33635. Was this one closed by accident?

I’m not able to reproduce this when running the test repo (Electron 17.1.2) on Ubuntu 22.04, which like Fedora 36 is also running GNOME 42. Wayland graphics. When I load System settings, go to Appearance, and click “Light” or “Dark”, Electron’s theme updates correctly along with the rest of the desktop.

I’ll try installing Fedora 36 to see if that changes things.

As an aside, I do see that the console log is triggered twice each time I toggle between light and dark:

shouldUseDarkColors: false, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
shouldUseDarkColors: false, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
shouldUseDarkColors: true, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
shouldUseDarkColors: true, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
shouldUseDarkColors: false, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
shouldUseDarkColors: false, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false

I’m mentioning it here since It’s possible that this is relevant to the bug and that second event is needed to make Electron’s theme change. It’s also possible that, this is a red herring, that the testcase registered for the event twice, or that Electron is generating unnecessary duplicate events 👀 :

I’ll try installing Fedora 36 to see if that helps in reproducing this issue.

@codebytere I believe you closed this issue by accident. Please reopen it

@codebytere Giving this another try. Can you please re-open this issue? It was closed by accident.

The work around posted here worked for me:

Gnome Tweaks -> Appearance -> Themes, Legacy Application -> Select Dark theme (Adwaita-dark)

I have also figured out for myself a way to script this:

gsettings set org.gnome.desktop.interface color-scheme "prefer-dark"
gsettings set org.gnome.desktop.interface gtk-theme "Adwaita-dark"

The first line is how Fedora 36 seems to “generally” handle dark mode, while the second covers those edge cases like vscode / electron.

Combining with https://github.com/electron/electron/issues/33635

@remlse But this will not follow the system theme change. Although it’s possible to write a script that would listen to the DBus theme change event and change it globally.

New install of Fedora 36 and I see this issue as well. Specifically with VS Code 1.67.2. Came here from: https://github.com/microsoft/vscode/issues/146804

Combining with #33635

This issue is #33635. Was this one closed by accident?

Problem solved in Chinese Communist Party ways.

@bash Night Theme Switcher can do this, too. But it’s somewhat cumbersome: Its main purpose is to switch to dark mode automatically, and you can’t turn this off officially. If you don’t want to have an automatic schedule, you can set the night schedule to 5:00 to 5:00 or similar, so it’s effectively always light mode, or you can set the night schedule to 5:01 to 5:00, so it’s effectively always dark-mode.

This issue is still there on Fedora 39 (Workstation Edition) running GNOME 45.2

Terminal output:

shouldUseDarkColors: false, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
shouldUseDarkColors: false, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
shouldUseDarkColors: true, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
[6046:0106/020111.827043:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
shouldUseDarkColors: false, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
[6046:0106/020130.378229:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
shouldUseDarkColors: true, shouldUseHighContrastColors: false, shouldUseInvertedColorScheme: false
[6046:0106/020134.019750:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!

shouldUseDarkColors seems to change but only the title bar changes to dark/light.

EDIT: The Open and Save As dialog boxes are white, other ones which appear like “Are you sure you want to … something” go dark when using “custom” dialog style.

It’s apparent that we won’t be getting a real fix…

I attached a video demonstrating the issue;

Note: the video doesn’t work (here in my Firefox). “Video can’t be played because the file is corrupt.”

I also use a ready-made extension for GNOME 42 which allows to force a theme switch for legacy applications (this is disabled by default in the extension settings) https://gitlab.com/rmnvgr/nightthemeswitcher-gnome-shell-extension I definitely recommend it to those who want to have real theme switching in GNOME 42 like in macOS.