[Bug]: "System" appearance stays light on KDE Plasma Wayland (Electron mis-resolves the color scheme) #19119

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. On KDE Plasma 6 (Wayland), set a dark system color scheme (Plasma global theme "Breeze Dark" in my case). Confirm it is dark system-wide:
   • gsettings get org.gnome.desktop.interface color-scheme → 'prefer-dark'
   • portal reports org.freedesktop.appearance color-scheme = 1 (prefer dark)
2. Fully quit T3 Code (desktop nightly, AppImage) and launch it again on Wayland.
3. Open Settings → Appearance and select "System".
4. The app renders light and stays light. It also fails to update when the system scheme changes while the app is running.

Expected behavior

With "System" selected and the OS in dark mode, the app should render in the dark appearance and follow live system color-scheme changes (as the explicit "Light" and "Dark" options do).

Actual behavior

The renderer's (prefers-color-scheme: dark) resolves to light from launch onward, so "System" paints the light theme even though the OS is dark. In the main process, nativeTheme.themeSource = "system" yields nativeTheme.shouldUseDarkColors === false. Selecting "Light" or "Dark" works, so only system-mode resolution is broken; switching away from "System" and back does not repair it.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261013.3053 (current nightly; issue is at the Electron layer and reproduces with the same bundled Electron build in an isolated window)

Environment

Arch Linux (rolling), KDE Plasma 6.7.5 Wayland; xdg-desktop-portal 1.22.1 with xdg-desktop-portal-kde 6.7.5; GTK 3.24.52 (theme Breeze-dark-gtk); T3 Code desktop nightly AppImage, bundled Electron 44.4.5 / Chromium 152.0.7977.130.

Logs or stack traces

# System state is dark:
$ gsettings get org.gnome.desktop.interface color-scheme
'prefer-dark'
$ gdbus call --session --dest org.freedesktop.portal.Desktop --object-path /org/freedesktop/portal/desktop --method org.freedesktop.portal.Settings.Read org.freedesktop.appearance color-scheme
(<<uint32 1>>,)   # 1 = prefer dark

# Minimal probe: hidden offscreen window on Electron 44.4.5 (the exact build
# bundled with the nightly), fresh profile, same Wayland session:
boot (untouched):              themeSource=system  shouldUseDarkColors=false  prefers-color-scheme=light
themeSource="dark":            shouldUseDarkColors=true
themeSource="system" (again):  shouldUseDarkColors=false  prefers-color-scheme=light   # wrong, system is dark

Cold start resolved light on 8 of 9 fresh-profile launches (system dark, portal correct); the ninth resolved dark and was then re-resolved incorrectly on the next theme event. A genuine color-scheme change while running can flip the app to the correct value, but a cold start never resolves dark and re-selecting "System" does not repair it.

Additional context (diagnosis)

• This matches upstream electron/electron#48736 (KDE Plasma Wayland; Chromium 142+ mis-resolves the system theme at startup and at runtime; upstream chromium issue 462191707) and the long-standing gap electron/electron#25925: Electron's nativeTheme does not consult the freedesktop Settings portal, unlike Chrome's DarkModeManagerLinux.
• Only the GTK-side path delivers correct values here: after routing the portal's Settings interface to the GTK backend (~/.config/xdg-desktop-portal/kde-portals.conf → org.freedesktop.impl.portal.Settings=gtk), a real color-scheme change reliably flips the app to the correct appearance; with the KDE Settings implementation the nativeTheme updated event fires with wrong values.
• Possible app-side direction (untested): in the desktop main process, subscribe to org.freedesktop.portal.Settings SettingChanged for org.freedesktop.appearance/color-scheme and drive ElectronTheme.setSource (apps/desktop/src/electron/ElectronTheme.ts) from it. dbus-next is already a dependency (see the portal code under apps/desktop/src/snapShot/), and this would also fix the native-chrome pieces that read shouldUseDarkColors (initial window background and splash). Re-asserting themeSource = "system" on the nativeTheme updated event is not sufficient (observed).
• Possibly related: #17732 (embedded browser panel "System" appearance ignored until re-selected) — different surface, similar staleness at the same Electron layer.

Workaround

Machine-level, verified working here:

1. Route the portal Settings interface to the GTK backend and restart xdg-desktop-portal.
2. Re-assert the system color scheme once whenever a new Chromium/Electron renderer starts (a small user service toggling gsettings set org.gnome.desktop.interface color-scheme for ~250 ms), since cold startup never resolves dark on its own.

Happy to share both if useful.