Skip to content

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) #209

Description

@gogosofta

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions