After startup, Desktop doesn't honor system theme changes (Linux)

[genericusername3]

• [x] I have searched open and closed issues for duplicates

---

Bug Description

Signal does follow system theme but does not react to changes to the GTK theme after startup. This is especially inconvenient when using the --start-in-tray option to receive notifications and using something like the Gnome extension "Night theme switcher" to change GTK themes depending on daytime.

Steps to Reproduce

1. Choose "System" in Preferences → Theme
2. Change GTK theme from dark to light or vice versa

Actual Result:

The Signal theme does not update with the GTK theme, even when switching to another theme (which works, don't worry) and back.

Expected Result:

The Signal theme should update with the GTK theme (at least after closing the window and re-opening it from the tray).

Screenshots

GNOME's appearance settings to the right (gnome-tweaks)

After changing GTK theme, Signal stays dark

When closing and re-opening the preferences, they become light. Signal itself, however, stays dark (even when closing the window [to tray]) until an app restart.

Platform Info

Signal Version: v1.40.1

Operating System: Linux (Manjaro Linux 20.2.1, GNOME Shell 3.38.3, Kernel 5.9.16)

Linked Device Version: Don't think this is needed, this only concerns the desktop client

Link to Debug Log

Don't think this is needed, this only concerns the desktop client

[gabrc52]

To me, it doesn't seem to honor the system theme at all, even after an app restart

[rr-]

I'd appreciate either this, or a way to tell Signal to switch the theme between dark and light.

[amadeusp]

Is there any work done to fix this? From reading through the comments this seems to be "broken" not only on Linux but also on macOS, correct?

I am on Manjaro 22.0.0 Sikaris, running GNOME 43.1, on Wayland 1.21.0-2 and for me the window decorations are the only thing that follow the "System" setting for "Appearance" > "Theme".

As long as "Appearance" > "Theme" is set to "System" the actual app UI is not following the system setting.

Changing the setting to "Dark" or "Light" respectively works flawlessly though.

Would be nice if "System" would work as well. :relaxed:

[indutny-signal]

@amadeusp this is a Linux-only issue, unfortunately. I don't think we actually acknowledged that, but this isn't the issue in Signal Desktop itself, but rather a one the electron.

[igalic]

perhaps we should link to the appropriate electron issue then? there seem to be a few https://github.com/electron/electron/issues?q=is%3Aissue+is%3Aopen+system+theme

[slynobody]

there are a bunch of open issues on this bug at electron-apps (like signal and others), all pointing back to electron itself.

you simply cant change the theme of electron-apps on konsole or os-level currently (electron is the last platform on linux with this problem) which renders all external tools on this useless. is there any news on this?

[Igetin]

The upstream issue in Chromium was fixed yesterday, 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.

The fix is included Chromium 114, which is due for a stable (Chrome) release on the 30th of May. Electron follows Chromium in its releases, so the fix should land in Electron stable 25.0.0 on the same day.

[nekohayo]

As issue #5155 seems to indicate, there is still yet another issue to fix in Electron: https://github.com/electron/electron/pull/38977

[Igetin]

Yes, Electron 25 did not actually yet adapt their API to reflect the Chromium changes, which causes the old workarounds to interfere with e.g. the dark mode setting in GNOME. They’ve been quiet on Electron’s side about the problem, and the original issue has actually been incorrectly closed for months despite comments by users and VS Code developers stating that the problem still exists.