Client: Systray has gone (linux)

[ruphy]

Hi all,

Keybase works perfectly (kbfs, GUI loads on demand), but since latest update the system tray has completely disappeared. No matter how many times or with how many switches I restart the application (systemd, run_keybase, ...), it is just no longer there.

Version:
keybase version 5.3.1-20200320154633+3e235215b3

DE: Elementary
All other system tray icons, including third party apps (even Electron-based, such as slack) correctly show

[fauust]

same here

OS: Debian Buster
Window manager: i3wm + polybar

[0p1um]

Same for me

OS: Debian Sid
Window manager: i3wm + i3block

[zonotope]

Same here. I have not confirmed by looking at the code, but i _think_ this issue is due to this upstream electron issue (which references a change in upstream chromium behavior).

Chromium, (and hence electron and keybase) no longer supports libappindicator, opting to support the StatusNotifier interface popularized by KDE instead. The problem is that a lot of linux desktop environments and system tray applications don't yet support StatusNotifier, and they still rely on libappindicator

This is a big problem for running keybase systems that don't yet support StatusNotifier (like mine), because if you accidentally close the keybase window, subsequent attempts to open it again by launching keybase just does nothing because it's already "launched", but running in the background.

I haven't figure out a way to get the window back after closing it without hard killing the keybase processes. This is extra problematic because about 3 processes all have to be killed for the app to finally pop open the window again after you run it, and many of those processes respawn if you kill them independently.

Making keybase open the app window if you try to launch it when it's already running will make a huge difference in mitigating this problem on systems without StatusNotifier support. Or, if there's another way to open the app window without the tedious process of killing all the keybase processes first, I'd love to know!

| OS | Window Manager | System Tray |
| ---- | ------------------------ | ----------------- |
| Arch Linux | StumpWM | Polybar |

Se related polybar issue

[dotenorio]

See my solution:

https://github.com/zulip/zulip-desktop/issues/910#issuecomment-608056150

[eli-schwartz]

@zonotope,

Are you using the Arch community package keybase-gui or the AUR keybase-bin? The former is maintained by me, and does not use run_keybase -- I recently added a workaround so that clicking on Keybase in the application menu will raise keybase to the foreground: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/keybase&id=7c3e4552a783343f05df7cb0f913148abc24e0a6

If you're using keybase-bin, then re-running run_keybase should kill all the programs for you, then restart them. You could also run /opt/keybase/Keybase to just make the program foreground itself.

[ruphy]

@dotenorio is that a proposal for the keybase folks?

[vladimiry]

@dotenorio is that a proposal for the keybase folks?

@ruphy that hack is a workaround for the limited scoped issue of the tray icon disappearing on some systems after the sleep/suspend mode (primarily affected the systems that use Gnome Shell). The upstream issue is here https://github.com/electron/electron/issues/22443.

[vdo]

Related:
https://github.com/vector-im/riot-web/issues/12518

[vdo]

using snixembed in i3 solved the issue for me

[fauust]

@vdo for me too (see https://github.com/polybar/polybar/issues/2010#issuecomment-618284256)

[powerman]

It's sad, but snixembed has it's own issues (keybase icon appears only if keybase is started after snixembed, clementine icon popup with current track is broken, telegram icon looks worse than without snixembed). :disappointed:

[vdo]

It's sad, but snixembed has it's own issues (keybase icon appears only if keybase is started after snixembed, clementine icon popup with current track is broken, telegram icon looks worse than without snixembed). disappointed

Yes of course, it needs to be running first and it's not the ideal, just a workaround, but I can live with it.

The ball is in WMs court now: https://github.com/i3/i3/issues/2088

[powerman]

Actually it turns out snixembed can be restricted to just keybase by separate DBUS instance, which resolves all issues with other application's icons. I've added this to my startup script and it works just fine:

(
    export DBUS_SESSION_BUS_ADDRESS=$(dbus-daemon --session --print-address --fork)
    snixembed --fork
    KEYBASE_AUTOSTART=1 run_keybase
)