tray: "Invalid Status Notifier Item" for Electron 43+ SNI items using well-known bus names

[burninc0de]

Update 2026-08-28 — Upstream Electron bug, not Waybar

This is not a Waybar/GDBus bug as originally diagnosed — thanks to @marcioflaviof and @boredland for narrowing it down.

Root cause: Electron 43.3+ registers SNI under org.freedesktop.StatusNotifierItem-PID-N but its Properties.GetAll/Get handler only answers on that well-known name, not on its unique name :1.XXX. Waybar's Gio::DBus::Proxy (correctly) resolves to the unique name -> get_cached_property_names() == [] -> Invalid Status Notifier Item.

Upstream: electron/electron#52674 — last good 43.2. Waybar broken from 43.3.0 through 43.4.x (e.g. Slack 43.4.0 fails on Waybar, see #5240 (comment)). On my Omarchy/Quickshell system 43.4.0-1 is still fine, latest 43.4.1-1 breaks — Quickshell's tray proxy apparently doesn't hit the unique-name path the same way.

Verified: Ping/Introspect OK on both names, GetAll FAIL on :1.XXX only.

Keeping open as tracker for Waybar workaround (Item::proxyReady() fallback/raw call or keep proxy on well-known name). See comments for workarounds.

---

Original report follows:

Environment:

• Waybar: 0.15.0.r959.g084d874-1 (waybar-git)
• Electron: 43.3.0
• Hyprland: 0.56.2
• Arch Linux, kernel 7.1.6

Reproduction:

1. Install Obsidian (obsidian package, uses Electron 43) with the "Tray" community plugin v0.3.5 by dragonwocky
2. Enable the tray icon in the plugin settings
3. Observe: no tray icon appears in Waybar

What happens:
Waybar logs:

[error] Invalid Status Notifier Item: org.freedesktop.StatusNotifierItem-<PID>-<N>, /StatusNotifierItem

The item is registered on D-Bus under a well-known bus name (org.freedesktop.StatusNotifierItem-PID-N), which is Electron 43+'s new SNI naming convention. g_dbus_proxy_get_cached_property_names() returns empty for this well-known name, so proxyReady() sees no Id or Category and invalidates the item.

Why it's a Waybar/GDBus issue (not Electron):
The properties are fully accessible via raw D-Bus calls — busctl get-property and dbus-send GetAll both return valid Id, Category, IconPixmap, etc. The problem is specifically that GDBus's proxy caching fails for well-known names of the form org.freedesktop.StatusNotifierItem-*.

Why other tray icons work:
Electron ≤39 and other apps use unique connection names like :1.724/StatusNotifierItem. GDBus caches properties fine for those. Electron 43+ changed to well-known names, exposing this GDBus proxy bug.

Possible fix:
proxyReady() in src/modules/sni/item.cpp should fall back to fetching Id and Category via raw g_dbus_connection_call_sync when get_cached_property_names() returns empty.

[the-nummer-zone]

i've been seeing this as well with discord clients. i've tried legcord and goofcord and neither of their icons showed up

[marcioflaviof]

Confirming this with a different Electron 43 app, plus a detail that I think changes the diagnosis.

Environment: Arch, waybar-git 0.15.0.r970.g09e69e0-1, WebCord 4.14.0-1 on electron43 43.3.0-1, Hyprland 0.56.2. Same error, same well-known name shape:

[error] Invalid Status Notifier Item: org.freedesktop.StatusNotifierItem-75624-1, /StatusNotifierItem

The proxy cache is empty because the app rejects the call, not because GDBus mishandles well-known names

The issue body concludes this is a GDBus/Waybar problem rather than an Electron one, on the grounds that busctl get-property and dbus-send GetAll both work. Those address the well-known name. GDBusProxy resolves a well-known name to its owner and sends to the unique name — and that is where it breaks:

call	→ org.freedesktop.StatusNotifierItem-75624-1	→ :1.599 (its own unique name)
org.freedesktop.DBus.Peer.Ping	OK	OK
org.freedesktop.DBus.Introspectable.Introspect	OK	OK
org.freedesktop.DBus.Properties.GetAll	OK (14 props)	FAIL
org.freedesktop.DBus.Properties.Get	OK	FAIL

Failure is org.freedesktop.DBus.Error.Failed: error occurred in GetAll (0).

Ping and Introspect succeed on both destinations, so the connection is alive and correctly addressed — only the Properties handler discriminates on the message destination. Replaying Waybar's exact call confirms the consequence:

p = Gio.DBusProxy.new_sync(bus, Gio.DBusProxyFlags.NONE, None,
                           "org.freedesktop.StatusNotifierItem-75624-1",
                           "/StatusNotifierItem", "org.kde.StatusNotifierItem", None)
p.get_name_owner()             # ':1.599'
p.get_cached_property_names()  # []  -> Id/Category empty -> item discarded

For comparison, on the same bus at the same moment, Slack (also Electron, registered under its unique name :1.45) and flameshot both return 14 cached properties and are accepted.

So GDBus is behaving correctly here — resolving to the unique name is the standard way to avoid owner-change races. The defect looks like it belongs to Electron's SNI implementation, which only answers property reads addressed to the well-known name it registered.

On the proposed fix

The suggested fallback in Item::proxyReady() still works as a workaround and would fix this for users today, since a raw call can be aimed at the well-known name. Worth landing on that basis — just noting it papers over an upstream bug rather than fixing a Waybar one, so it probably also deserves an Electron issue.

Workaround without patching

Running the app under an older Electron restores the icon, because Electron 42 still registers under a unique connection name:

electron42 /usr/lib/webcord    # instead of the packaged electron43 launcher

Item accepted, icon renders, no Waybar changes.

Verified only for WebCord on Electron 43.3.0 here — I have not checked whether Obsidian, legcord or goofcord fail identically, though the identical error and naming make it likely.

[the-nummer-zone]

i found a fix for the moment in electron/electron#52674, suggesting downgrading electron43 to 43.2 which restored legcord's tray icon for me

definitely cements this as a bug with electron

[boredland]

same here. slack 4.51.191 (electron 43.4.0), waybar 0.15.0-2, sway.

might be narrower than gdbus caching. slack answers GetAll on the well-known name but errors on the unique name:

$ busctl --user call org.freedesktop.StatusNotifierItem-15401-1 /StatusNotifierItem \
    org.freedesktop.DBus.Properties GetAll s org.kde.StatusNotifierItem
a{sv} 14 ... "Category" s "ApplicationStatus" "IconPixmap" ... "Id" s "Slack_status_icon_1" ...

$ busctl --user call :1.68 /StatusNotifierItem \
    org.freedesktop.DBus.Properties GetAll s org.kde.StatusNotifierItem
Call failed: error occurred in GetAll

dbus-monitor shows gdbus resolves the owner and then addresses the unique name:

:1.49 -> org.freedesktop.DBus GetNameOwner "org.freedesktop.StatusNotifierItem-15401-1"
  <- ":1.68"
:1.49 -> :1.68 /StatusNotifierItem Properties.GetAll "org.kde.StatusNotifierItem"
  <- org.freedesktop.DBus.Error.Failed "error occurred in GetAll"

so the props aren't uncached, the request just goes to an address electron won't answer on. keeping the proxy on the well-known name may be enough, without the raw-call fallback.

items on unique names (tailscale :1.3, discord :1.66) unaffected.

[burninc0de]

Update from OP — confirmed this is upstream, not Waybar.

What I initially read as a GDBus cache bug is Electron answering GetAll only on the well-known name:

busctl --user call org.freedesktop.StatusNotifierItem-15401-1 /StatusNotifierItem org.freedesktop.DBus.Properties GetAll s org.kde.StatusNotifierItem # OK (14 props)
busctl --user call :1.68 /StatusNotifierItem org.freedesktop.DBus.Properties GetAll s org.kde.StatusNotifierItem          # Call failed: error occurred in GetAll

dbus-monitor shows GDBus resolves owner then addresses :1.XXX, exactly as described in #5240 (comment) and #5240 (comment). Upstream is electron/electron#52674.

Workaround I used (not ideal):

On my Omarchy/Quickshell system 43.4.0-1 is still fine, latest 43.4.1-1 is broken. On Waybar 43.4.0 is already broken, so Waybar users likely need 43.2.

# my case (Omarchy + Quickshell): downgrade latest -> 43.4.0 works
sudo pacman -U https://archive.archlinux.org/packages/e/electron43/electron43-43.4.0-1-x86_64.pkg.tar.zst
pacman -Q electron43  # should print 43.4.0-1 after (was 43.4.1-1)

# Waybar hosts: likely need 43.2 instead
# sudo pacman -U https://archive.archlinux.org/packages/e/electron43/electron43-43.2.1-1-x86_64.pkg.tar.zst

Caveats: needs IgnorePkg = electron43 in /etc/pacman.conf or next -Syu re-breaks it, archive URLs expire, and you miss security fixes. More stable is per-app electron42 /usr/lib/webcord (or electron43-bin 43.2 from AUR) as @marcioflaviof noted.

Happy to close if maintainers prefer to track the workaround separately — leaving open for now per discussion that the Item::proxyReady() fallback is still worth landing.

[teivng]

Root-caused this. Electron 43.4.1 (Chromium 150.0.7871.224) changed its tray registration from a bare object path (/org/chromium/StatusNotifierItem/1, which waybar accepts) to a combined bus_name/object_path string:

RegisterStatusNotifierItem("org.freedesktop.StatusNotifierItem-<pid>-1/StatusNotifierItem/1")

Watcher::handleRegisterItem only handles a leading-/ object path or a plain bus name, so it validates the whole combined string with g_dbus_is_name(), fails, and replies InvalidArgs — and on that error Electron permanently destroys the tray icon (it won't retry, even after a watcher restart; the app itself must be restarted once a fixed waybar is running). That's why Signal-Desktop 8.25+ has no tray icon while apps on Electron ≤ 43.4.0 (e.g. current Slack, which registers a bare bus name) still work. KDE's watcher accepts the combined form.

Fix in #5287: split the string at the first / when it doesn't start with one; the two existing forms are untouched. Verified against Signal 8.25.0 on waybar 0.15.0/Hyprland — icon registers and survives window close/reopen cycles, other tray items unaffected.

[burninc0de]

yup. fix confirmed. thanks!