xapp-sn-watcher publishes IconName=" " instead of falling back to IconPixmap when a StatusNotifierItem's property Get returns Error.Failed (Slack 4.51.191 / Electron 43.4.0)

Inizia dalla gestione di xapp-sn-watcher delle chiamate Get per le singole proprietà di StatusNotifierItem, quindi segui il percorso di fallback esistente da IconPixmap a PNG. Riproduci la risposta IconName non riuscita descritta per Slack e verifica che una ricerca IconName o IconThemePath in errore pubblichi comunque l’icona pixmap valida invece di un IconName composto da un singolo spazio.

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.