The application does not follow the system theme on GNOME 42

[rene-coty]

When I set "follow system theme" in the appearance menu of the application on Fedora 36 (GNOME 42), it doesn't follow any change between dark and light theme of the GNOME 42 desktop environment.. (see video file below)

https://user-images.githubusercontent.com/95506494/172812253-27042bd0-0be4-4e50-8383-408833f44201.mp4

[LuisArtDavila]

Is this an upstream issue, maybe?

[rene-coty]

I made a report to the Signal devs and they told me they weren't concerned by unofficial redistributions of Signal...

[bermeitinger-b]

I assume this is a flatpak issue and not upstream.

The program is at least somewhat sandboxed and doesn't have direct access to all your files and hence your settings. It doesn't "know" your theme.

You might workaround by giving it full host access.

[rene-coty]

You might workaround by giving it full host access.

I tried to do so with Flatseal but it didn't change anything yet..

[moshiur-raj]

Signal uses gtk3. Gnome control panel sets the theme for gtk4 apps. Have you tried using gnome-tweaks to set the theme?

[rene-coty]

Same result, it didn't change anything excepted the color of the application's titlebar

[steffen-stell]

I've had the same issue on a fresh install of Fedora 37 despite having org.gtk.Gtk3theme.Adwaita-dark installed and legacy theming set to Adwaita-dark via Tweaks. But I also had another install where Signal's theming worked just fine. I noticed that on the other system, I used org.gtk.Gtk3theme.Breeze-Dark for legacy apps. Switching to that as the legacy app theme resolved to problem for me.

Don't know why, but the issue seems to be with the Adwaita legacy dark theme specifically.

[systeminbits]

Apparently it's an upstream bug in Chromium (Issue 998903), which causes the not following of the system's preferred color scheme on Linux. By extension, Electron (which Signal uses for the desktop client) is affected too (e.g. Issue 33635).

[Igetin]

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.

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.

[xplosionmind]

Same issue here, but on GNOME 44.1, too. Using Fedora 38.

[quazar-omega]

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.

I'm still facing the issue on KDE Plasma despite the upstream fixes

========= System info =========
App version: 6.30.2
Environment: production
Node version: 18.15.0
OS version: #1 SMP PREEMPT_DYNAMIC Sat Sep  2 16:36:06 UTC 2023
Time: 1695070642573
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Signal/6.30.2 Chrome/114.0.5735.289 Electron/25.8.1 Safari/537.36

[Igetin]

Only half of the upstream fixes are complete, and that is the Chromium side of things. Electron now includes a Chromium version that has those fixes, but their own API still has not been adapted to reflect those Chromium changes.

This means that Electron’s old workarounds still interfere with newer desktop environments that use the XDG settings portal for the color scheme preference.

Unfortunately, the status of this is unknown on Electron’s part, as they have falsely closed the original issue on their side. Users and (VS Code) developers have been stating this in the issue for months, but they have not been responding.

There is an open pull request on Electron’s side about this, but it has not seen developer activity since July.

You can read more details in the closed issue on Electron’s GitHub, particularly this comment of mine.