No tray icons for Electron apps

[notramo]

System

• xuname:
  Void 4.19.37_1 x86_64 GenuineIntel uptodate rFFFFFF
• package:
  riot-desktop (don't know which version)

Expected behavior

Riot Desktop, and other Electron apps has system tray support.

Actual behavior

No system tray icon for Electron apps.
A few months ago it worked (I don't know exactly).
(GTK and QT apps still have working tray icons.)

Steps to reproduce the behavior

Launch any Electron app that should have system tray support.

[pbui]

Hmm. I just ran the slack-desktop client, which is also an Electron app, and its tray icon displays normally (I'm using polybar with i3wm). I'm not sure if this is a general problem.

[pbui]

I also just ran riot-desktop, and once again, I was able to see a tray icon... I'm thinking this might be a local user configuration issue.

[notramo]

I am using i3-bar.

[Bendodroid]

Check if libappindicator packages are installed. See: element-hq/element-web#9477

[DoctorSubtilis]

With 1.2.2 the problem was not fixed for us (Kubuntu 18.04).

[glaubersm]

I have the same problem on Void + KDE Plasma desktop environment.
Discord (installed via flatpak), Riot and Skype are some apps affected.

[bugger11]

Check if libappindicator packages are installed. See: vector-im/riot-web#9477

Thank you for that.

I am on Arch Linux with KDE. I first installed libappindicator-gtk3 but that did not resolve the issue. So I reluctantly tried installing libappindicator-sharp (which pulls in mono), and that did resolve the issue. But I would prefer not to have to install mono. Is mono really a dependency now?

[ProjectMoon]

I'm having this issue on KDE on X11. In Wayland, the indicators work fine. Both Riot and Signal Desktop output a complaint about dbus when starting up on X11, but not on Wayland.

The error is: Unable to get the session bus: Unknown or unsupported transport “disabled” for address “disabled:”

I don't know if it's the same root cause as other people in this issue, but maybe it is helpful.

[ProjectMoon]

It should also be noted they work fine in Sway, if Sway is run via dbus-run-session. So it seems like some kind of issue with starting dbus properly when logging in to KDE for some reason.

[ghost]

As @ProjectMoon suggested in the issue referenced above, i am now using dbus-run-session. The icon of riot-desktop is still missing. i want to note that the icon of telegram-desktop works fine (is that application also electron based?)
Terminal Output launching riot-desktop:

node[7908]: pthread_create: Invalid argument
No update_base_url is defined: auto update is disabled
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false".  It will change to be "true" in Electron 9.  For more information please check https://github.com/electron/electron/issues/18397

[ProjectMoon]

What system tray application are you using?

[ProjectMoon]

I am able to reproduce this issue with both Awesome window manager and stalonetray (standalone sys tray). I use nm-applet as a control. Starting nm-applet makes it appear in these X-based trays, but starting Riot does not make it appear in the tray. However, Riot does appear in Waybar (usually used with Sway) and KDE. Off the top of my head, this sounds like some kind of dependency issue, where a library that is is needed for integration with these trays is not present. Not sure if it would need to be a build-time dependency or runtime only.

[ProjectMoon]

It might also be some incompatibility with these trays and newer versions of electron. Hard to say.

[Johnnynator]

i want to note that the icon of telegram-desktop works fine (is that application also electron based?)

Telegram is Qt based.

[ProjectMoon]

This looks like a more up-to-date upstream issue for this problem: element-hq/element-web#12518

Summary basically is: Electron 8 is based on a newer version of Chromium, which changes how the tray icon works. I guess KDE handles that, while other sys trays do not.

[ProjectMoon]

For anyone not able to see the tray icon, perhaps try using https://git.sr.ht/~steef/snixembed. I have not had any luck in getting it to work yet, but at least one person in the upstream issue said it solved their problem.

[ProjectMoon]

OK, after much testing, snixembed is the "solution" here. It works with awesome wm and stalonetray. I will create an XBPS package for snixembed.

This is an upstream issue though, in the window managers. They need to update themselves to support the StatusNotifierItem APIs for Electron 8+ applications to work properly with the system tray.

[ProjectMoon]

snixembed is now available in the Void repositories. Anyone using i3, awesome, etc should try installing and configuring it to get Riot's icon to show up in the system tray.

[ghost]

I can comfirm that the icon is showing up again using dwm window manager. Thank you for creating a package for this.

[2xsaiko]

Does executing

source "$HOME/.dbus/session-bus/$(cat /var/lib/dbus/machine-id)-${DISPLAY:1}"
export DBUS_SESSION_BUS_ADDRESS

and then running the program through the terminal make the icon appear? I have a similar issue, not sure if it's related, but that makes it work.

In my case, DBUS_SESSION_BUS_ADDRESS doesn't get set which causes Discord and Spotify to not be able to send notifications, create a tray icon, and provide media player controls.

Obviously, that's a workaround but I'm not sure how to get that variable to be auto exported.

Using SDDM and Plasma desktop with X11.

[ProjectMoon]

There are two different issues, both with similar symptoms:

• Using SDDM to log in to KDE X11 does not set the DBUS_RUN_SESSION variable. This can be fixed by running KDE in dbus-run-session or something similar.
• Electron dropped support for XEmbed. This is what snixembed fixes. However, some people re-ported the XEmbed to the newer versions of Electron, so snixembed shouldn't be necessary that long.

[Fluffkin]

@2xsaiko Yes the source / export trick does work for me
My problem is AppImage programs not finding libappindicator on dbus (not the snixembed problem)

In my case, DBUS_SESSION_BUS_ADDRESS doesn't get set which causes Discord and Spotify to not be able to send notifications, create a tray icon, and provide media player controls.

Obviously, that's a workaround but I'm not sure how to get that variable to be auto exported.

It's a cludge, but you can edit the desktop file in /usr/share/xsessions and add "dbus-run-session" to the Exec line. So mine is now "Exec=dbus-run-session /usr/bin/startplasma-x11".

[ProjectMoon]

It should be noted that will be patched into the KDE 5.19 release.

[Johnnynator]

KDE 5.19 Should land in the repo somewhen tromorrow (if I don't see anything broken)

[Fluffkin]

KDE 5.19 Doesn't seem to fix the problem for me.

"Riot" and "Wire" won't show a systray icon unless I run the session with "dbus-run-session" (which worked fine in 5.18), but adding dbus-run-session to the startplasma-x11 exec line now seems to cause other problems in KDE.

EDIT: The workaround now seems to be: Add "dbus-run-session" to the Exec line in .desktop files for Wire / Riot / Electron Apps that won't show a systray icon, and remove it from /usr/share/xsessions/plasma.desktop (if you had added it in there).

EDIT2: Nope that doesn't work. When wire tries to change the systray icon for an incoming message it hangs and needs to be force quit. The only solution now is to use the

source "$HOME/.dbus/session-bus/$(cat /var/lib/dbus/machine-id)-${DISPLAY:1}"
export DBUS_SESSION_BUS_ADDRESS

Trick from above in a wrapper script that then launches wire / riot / whatever, then change the desktop file to point at your wrapper script.

EDIT3: Well this is embarrassing. (I'll shut up now). If I put:

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
        export $(dbus-launch)
fi

in ~/.xprofile, everything seems to get set up correctly.

[ericonr]

I believe this can be closed?

[Johnnynator]

Yeah, I suppose so.