Regression: v39 incorrectly resolves the system theme (light/dark) at runtime and also calculates nativeTheme.shouldUseDarkColors incorrectly at runtime

Preflight Checklist

I have read the Contributing Guidelines for this project.
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

39.0.0

What operating system(s) are you using?

Other Linux

Operating System Version

Archlinux + KDE + Wayland

What arch are you using?

x64

Last Known Working Electron version

38.5.0, 39.0.0-alpha.5 (broken in 39.0.0-alpha.6, v39.0.0-alpha.5...v39.0.0-alpha.6)

The Chromium v142 upgrade caused the regression. v38.x is working correctly.

Does the issue also appear in Chromium / Google Chrome?

No

Expected Behavior

When I change the system theme (I'm using latest KDE Plasma v6.5.1 + Wayland), electron should be able to recognize it at runtime. It currently recognizes it correctly on startup, but doesn't work if the system theme is changed during runtime.

Actual Behavior

When I change the system theme at runtime (electron app running), electron v39 doesn't correctly recognize the theme. shouldUseDarkColors is reported incorrectly (inverse). This causes things like "window.matchMedia('(prefers-color-scheme: dark)');" to be reported incorrectly. This is very recent regression as this works perfectly fine when I revert back to using any v38.x.

Testcase Gist URL

https://gist.github.com/lone-cloud/2211e0b707c8c8771eb060d9ad9c403f

Additional Information

No response

Thanks for reporting!

Would you be able to download Electron Fiddle, use it to create a small sample app that allows maintainers to reproduce this issue, and upload it as a GitHub gist from Fiddle?
Would you be able to test which v39 nightly/alpha/beta version broke this? You can easily switch Electron versions in Fiddle. (Might need to enable prereleases in the Fiddle settings.)

@lone-cloud

Hello @lone-cloud. Thanks for reporting this and helping to make Electron better!

Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

Now adding the blocked/need-repro Needs a test case to reproduce the bug label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.

I understand that this is an open source project and you guys are probably very short staffed on capable maintainers and do not have the capacity to deeply investigate all the reported issues here. Nevertheless, asking me to download some tools to code up repro code is not a respectful use of my time. I am perfectly content staying on the v38.5 branch indefinitely should you choose to ignore this bug.

You can reproduce this bug by comparing the gerbil v1.8.0 release (electron v39.0) vs gerbil v1.8.1 release (electron v38.5) from here: https://github.com/lone-cloud/gerbil/releases
You could run the .appimage from the release on Linux. I tested on latest KDE plasma 6.5.1 + Wayland by switching between breeze (light) and breeze dark (dark) themes during app runtime. The system theme switch gets reflected correctly in v38.x, but not in v39.0. This is strictly an electron runtime theme-switching issue and the system theme does get resolved correctly by electron on app start in both versions.

Thanks for your reply! Electron is a small team. Unfortunately, we only have the capacity to investigate issues with testcase gists. We don't have the time to create testcase gists for all issues ourselves, and unfortunately, we don't have time to debug full applications.

I know this is not a proper fix, but if anyone's interested - I've implemented a workaround for KDE Plasma, which globally "fixes" this behavior for all running electron applications. It's not perfect, but it's something. Maybe a workaround will also be useful for someone in diagnosing / fixing the issue itself.

Link: Electron-theme-fixer-for-KDE-Plasma

I am using Arch Linux/Plasma/Wayland, and the system dark/light mode change is not detected by VS Code until I restart VS Code. If this is a difficult issue to fix due to the diverse nature of Linux, how about adding one small workaround? You could add a simple command in the command pallet like > Re-evealuate OS theme.. At least this should be better than restarting VS Code.

If this is a difficult issue to fix due to the diverse nature of Linux

It’s not, it’s relatively clear what happens at this point: https://issues.chromium.org/issues/462191707#comment20

the issue seems to happen when there are multiple portal backends installed (e.g., xdg-desktop-portal-gtk and xdg-desktop-portal-gnome) where Chrome ends up listening to one backend while theme changes broadcast through another.

The theme actually switches — briefly. In Electron, the UI flashes light for a moment before immediately reverting to dark. This means the signal is processed and the theme change is applied, but something internal overrides it back.
The revert is not triggered by any external signal. A full DBus capture during the transition shows no color-scheme=1 (dark) signal being sent. The override happens entirely within the application.

@MinikPLayer

@MinikPLayer , why not fix it instead by just loading another GTK module, one that emits gtk-application-prefer-dark-theme signal after CSS reload? Much simpler than a file monitor.

I can still reproduce this with VS Code 1.139.1 / Electron 43.6.0 on Arch Linux, KDE Plasma, Wayland.

Originally I reported this through VS Code as microsoft/vscode#316427, which was closed as a duplicate of this issue.

Current behavior:

Changing KDE between dark/light updates org.freedesktop.appearance color-scheme correctly:
- dark: uint32 1
- light: uint32 2
However, inside VS Code:
```
window.matchMedia('(prefers-color-scheme: dark)').matches
```
remains true after switching from dark to light.
Completely restarting VS Code makes it detect the correct theme again.
Developer: Reload Window does not fix it.

I also tried the GTK Settings portal workaround.

My user portal config is:

[preferred]
default=kde
org.freedesktop.impl.portal.Settings=gtk

xdg-desktop-portal-gtk.service is active, and I logged out/in after changing the configuration. The problem still occurs.

Interestingly, with an earlier VS Code/Electron version I also saw another variant of the same problem: runtime theme detection became inverted, i.e. light system theme selected the dark VS Code theme and dark system theme selected the light VS Code theme.

So on my system the behavior across versions has been roughly:

initially: runtime theme changes were ignored until application restart
for some time: runtime switching worked
another version: light/dark detection became inverted
currently, with Electron 43.6.0: runtime changes are ignored again

The xdg-desktop-portal value itself changes correctly, while Electron's prefers-color-scheme state does not.

Reproduced on niri/Wayland with Electron 43.1.0 and visibly in Discord (Electron 42.9.0). On a theme change, a minimal nativeTheme probe briefly reported the new mode, then reverted to its startup mode within about 154 ms, while the Settings portal retained the new preference.

A full application restart selected the correct theme; a client reload did not. Selecting only the GTK Settings backend removed duplicate SettingChanged signals but did not fix the behavior. One-shot synthetic dconf Writer.Notify signals, including one sent after a 200 ms delay, did not help either.

A potentially relevant upstream fix landed in Chromium. It matches the brief switch and reversal observed in my niri/Wayland probe, but I haven't verified that it resolves this Electron issue.

Note: Electron 45 alpha now uses Chromium 156, which contains the change.

Additional observation on CachyOS, KDE Plasma 6.7.5, Wayland:

OpenChamber and Teams for Linux both bundle Electron 43.7.0 / Chromium 150.0.7871.250. OpenChamber briefly adopted dark mode and reverted; Teams required restarting. The desktop portal reported the correct dark preference.

Changing only the GTK application style from Breeze to Adwaita through KDE:

busctl --user call org.kde.GtkConfig /GtkConfig org.kde.GtkConfig setGtkTheme s Adwaita

followed by a light→dark cycle left both already-running applications dark, without restarting either. Plasma’s automatic switching and Breeze global themes remained enabled; no portal-backend changes or application patches.

This is an initial observation, not yet a confirmed durable workaround: the next scheduled transition remains untested. Changing GTK styles might simply invalidate stale state. Sharing in case that distinction helps reproduce or diagnose the regression.

Still present in Electron 44.4.3 (seen in Claude Desktop, reported as anthropics/claude-code#100295) on Fedora 44, KDE Plasma 6.7.5 Wayland (xdg-desktop-portal 1.22.1, KDE and GTK backends, gtk3 3.24.52).

Minimal probe: nativeTheme.themeSource = 'system', a hidden BrowserWindow, logging nativeTheme.shouldUseDarkColors and the page's matchMedia('(prefers-color-scheme: dark)') on updated and every few seconds. At each plasma-apply-colorscheme switch the portal sends the correct color-scheme at once, and updated fires at the same moment, but both values report the previous mode and stay there. So the app is always one switch behind. --gtk-version=4 gives the same result.

It looks like the GTK theme colors are read before kde-gtk-config has rewritten ~/.config/gtk-3.0/colors.css. A GTK theme reload a few seconds later (gsettings set org.gnome.desktop.interface gtk-theme Adwaita, then back to Breeze) fires updated again with the correct value. We use that as a workaround from a script that runs after each switch.

fix(desktop): follow live system light/dark changes on Linux

@lone-cloud

50. Based on my linked chromium issue above, nobody is looking into this issue and no progress has been made. It's currently up to the user to patch their system to work around this bug. What's worked great for me is to configure my system to use the GTK portal instead of the one that came preconfigured with kde.

@lone-cloud The chromium issue you mentioned has been marked as fixed on September 18 with this change. Also, Chrome now follows theme changes that were broken before.

Nice, confirmed fixed 🥳

That change landed in Chromium 153 which is used by Electron 45!

I just reproduced the issue with electron 43 from npm and confirmed that it’s no longer there in electron 45 from npm.

(Interestingly the Arch Linux build of Electron 43 also doesn’t have the issue which is probably caused by using system libs instead of being compiled against ancient Debian GTK like the npm builds)

I haven't been following this issue and switched to gnome from kde, which doesn't have this bug, for the sake of stability.

Going to close this issue as complete as others have pointed out that it's now fixed.

Navigation Menu

Repository navigation

Regression: v39 incorrectly resolves the system theme (light/dark) at runtime and also calculates nativeTheme.shouldUseDarkColors incorrectly at runtime #48736

Preflight Checklist

Electron Version

What operating system(s) are you using?

Operating System Version

What arch are you using?

Last Known Working Electron version

Does the issue also appear in Chromium / Google Chrome?

Expected Behavior

Actual Behavior

Testcase Gist URL

Additional Information

31 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Regression: v39 incorrectly resolves the system theme (light/dark) at runtime and also calculates nativeTheme.shouldUseDarkColors incorrectly at runtime #48736

Description

Preflight Checklist

Electron Version

What operating system(s) are you using?

Operating System Version

What arch are you using?

Last Known Working Electron version

Does the issue also appear in Chromium / Google Chrome?

Expected Behavior

Actual Behavior

Testcase Gist URL

Additional Information

Activity

nikwen commented on Oct 30, 2025

electron-issue-triage commented on Oct 30, 2025

lone-cloud commented on Oct 30, 2025

nikwen commented on Oct 30, 2025

31 remaining items

MinikPLayer commented on Aug 14, 2026

HubKing commented on Sep 7, 2026

flying-sheep commented on Sep 7, 2026

dcolascione commented on Sep 20, 2026

lazbaphilipp commented on Sep 28, 2026

anton-rudeshko commented on Oct 3, 2026

anton-rudeshko commented on Oct 4, 2026

bernhardberger commented on Oct 6, 2026

Tokra110 commented on Oct 7, 2026

KayJay7 commented on Oct 30, 2026

flying-sheep commented on Oct 30, 2026

lone-cloud commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions