Environment
- Linux Mint (zena), Cinnamon 6.6.9, X11
- xapps-common / libxapp1 3.2.2+zena
- Slack 4.51.191 (bundles Electron 43.4.0)
Symptom
Slack's tray icon renders as a broken-image / exclamation placeholder in the XApp Status applet, and right-clicking it does nothing (no menu). Downgrading Slack to 4.51.180 (Electron 43.1.1) restores both the icon and the menu.
Diagnosis
Slack 4.51.191 registers its StatusNotifierItem correctly and serves a valid 22×22 ARGB IconPixmap plus a complete com.canonical.dbusmenu layout — GetAll on org.kde.StatusNotifierItem succeeds and returns the pixmap. (This differs from #208, where GetAll itself fails.)
What fails here is the individual property Get:
$ dbus-send --session --print-reply --dest=org.freedesktop.StatusNotifierItem-30169-1 \
/StatusNotifierItem org.freedesktop.DBus.Properties.Get \
string:org.kde.StatusNotifierItem string:IconName
Error org.freedesktop.DBus.Error.Failed: error occurred in Get
# same for IconThemePath
xapp-sn-watcher then publishes the item to the applet with IconName set to a single space, and never writes the pixmap to /dev/shm/xapp-tmp-*.png as it does for other pixmap-only items:
Icon: "nextcloud" "/dev/shm/xapp-tmp-0x...-1.png" OK
Icon_1: "viberpc" "/dev/shm/xapp-tmp-0x...-0.png" OK
Icon_2: "org.freedesktop.statusnotifieritem-30169-1" " " BROKEN
Icon_3: "telegramdesktop" "org.telegram.desktop-symbolic" OK
Icon_4: "blueman" "blueman-tray-symbolic" OK
The distinguishing factor is precisely how each app's SNI answers a Get for IconName:
| Item |
Get IconName |
Result |
| Viber |
"" (success) |
pixmap serialized to PNG, works |
| Nextcloud |
"" (success) |
pixmap serialized to PNG, works |
| Telegram |
theme name (success) |
theme icon, works |
| Slack 4.51.191 |
org.freedesktop.DBus.Error.Failed |
" ", broken |
Viber also returns an error for IconThemePath, but a well-formed org.freedesktop.DBus.Error.UnknownProperty, and is handled fine. It appears a generic Error.Failed aborts icon resolution before the IconPixmap fallback is reached, whereas UnknownProperty / empty-string does not.
Ruled out
- Not a registration-order race:
xapp-sn-watcher was restarted with Slack already fully running and signed in; the item is still published as " ".
- Not a missing pixmap:
GetAll returns a valid 22×22 ARGB IconPixmap.
- Not a broken menu:
com.canonical.dbusmenu.GetLayout on the item returns the full, correct menu tree — so the dead right-click is downstream of the unusable icon, not a separate menu fault.
- Not desktop-hint related: launching Slack with
XDG_CURRENT_DESKTOP=Unity changes nothing.
- Only one
xapp-sn-watcher instance running; other SNI items on the same bus work correctly.
Upstream context
The Slack side is an already-fixed Electron regression. Electron 43.4.0 broke this; Electron 43.4.1 fixed it in electron/electron#52952, whose release note explicitly names Cinnamon:
Fixed Tray icons not appearing (and their menus not opening) on Linux desktops that address the StatusNotifierItem by its unique D-Bus name or via the org.freedesktop.StatusNotifierItem interface, such as GNOME with the AppIndicator extension, Cinnamon and XFCE.
Consistent with that, the working Slack 4.51.180 registers on its unique bus name (:1.610/StatusNotifierItem), while the broken 4.51.191 registers the well-known org.freedesktop.StatusNotifierItem-<pid>-1 name.
So affected apps will recover as they pick up Electron ≥ 43.4.1. But xapp-sn-watcher arguably shouldn't degrade to an unusable icon when a client's property getter errors — it already has a working IconPixmap in hand.
Suggested fix
Treat an errored Get on IconName / IconThemePath the same as absent-or-empty, and fall through to the existing IconPixmap → PNG path rather than publishing IconName=" ". This is the same tolerance suggested in #208, applied to the per-property Get path rather than GetAll.
Possibly the same root cause as #208 (Signal-Desktop 8.24.1 also ships Electron 43.4.0); filing separately because the failing D-Bus call and the resulting symptom differ.
Environment
Symptom
Slack's tray icon renders as a broken-image / exclamation placeholder in the XApp Status applet, and right-clicking it does nothing (no menu). Downgrading Slack to 4.51.180 (Electron 43.1.1) restores both the icon and the menu.
Diagnosis
Slack 4.51.191 registers its
StatusNotifierItemcorrectly and serves a valid 22×22 ARGBIconPixmapplus a completecom.canonical.dbusmenulayout —GetAllonorg.kde.StatusNotifierItemsucceeds and returns the pixmap. (This differs from #208, whereGetAllitself fails.)What fails here is the individual property
Get:xapp-sn-watcherthen publishes the item to the applet withIconNameset to a single space, and never writes the pixmap to/dev/shm/xapp-tmp-*.pngas it does for other pixmap-only items:The distinguishing factor is precisely how each app's SNI answers a
GetforIconName:Get IconName""(success)""(success)org.freedesktop.DBus.Error.Failed" ", brokenViber also returns an error for
IconThemePath, but a well-formedorg.freedesktop.DBus.Error.UnknownProperty, and is handled fine. It appears a genericError.Failedaborts icon resolution before theIconPixmapfallback is reached, whereasUnknownProperty/ empty-string does not.Ruled out
xapp-sn-watcherwas restarted with Slack already fully running and signed in; the item is still published as" ".GetAllreturns a valid 22×22 ARGBIconPixmap.com.canonical.dbusmenu.GetLayouton the item returns the full, correct menu tree — so the dead right-click is downstream of the unusable icon, not a separate menu fault.XDG_CURRENT_DESKTOP=Unitychanges nothing.xapp-sn-watcherinstance running; other SNI items on the same bus work correctly.Upstream context
The Slack side is an already-fixed Electron regression. Electron 43.4.0 broke this; Electron 43.4.1 fixed it in electron/electron#52952, whose release note explicitly names Cinnamon:
Consistent with that, the working Slack 4.51.180 registers on its unique bus name (
:1.610/StatusNotifierItem), while the broken 4.51.191 registers the well-knownorg.freedesktop.StatusNotifierItem-<pid>-1name.So affected apps will recover as they pick up Electron ≥ 43.4.1. But xapp-sn-watcher arguably shouldn't degrade to an unusable icon when a client's property getter errors — it already has a working
IconPixmapin hand.Suggested fix
Treat an errored
GetonIconName/IconThemePaththe same as absent-or-empty, and fall through to the existingIconPixmap→ PNG path rather than publishingIconName=" ". This is the same tolerance suggested in #208, applied to the per-propertyGetpath rather thanGetAll.Possibly the same root cause as #208 (Signal-Desktop 8.24.1 also ships Electron 43.4.0); filing separately because the failing D-Bus call and the resulting symptom differ.