Ok, I used electron 44 alpha that uses Chrome 152 and now there is another similar error, notification still fail.
Chromium 152 (Electron 44) changes the failure mode: now a name-ownership denial
Testing an updated Electron app on GNOME/Ubuntu with strict confinement shows the tray icon regression has shifted, not resolved, across recent Chromium versions. There are now two distinct snap-incompatible behaviors:
Chromium 150-151 (Electron 43): object-path denial
Chromium commit 7852522 (“Fix D-Bus status icon collision and Wayland suppression”) changed the exported StatusNotifierItem object path:
-const char kPathStatusNotifierItem[] = "/StatusNotifierItem";
+const char kPathStatusNotifierItem[] = "/org/chromium/StatusNotifierItem";
It also appends a per-process counter, producing /org/chromium/StatusNotifierItem/1. The unity7 template only allows /{StatusNotifierItem,org/ayatana/NotificationItem/*}, so the new path is denied:
apparmor="DENIED" operation="dbus_method_call" bus="session"
path="/org/chromium/StatusNotifierItem/1"
interface="org.freedesktop.DBus.Properties" member="Get"
label="snap.<app>.<app>" peer=gnome-shell
Chromium 152 (Electron 44): well-known name-ownership denial
Chromium commit 8043132 (“Fix status icon collision on shared D-Bus connection”, crbug.com/530633700) restores the object path back to /StatusNotifierItem, so the path denial above is gone. But to disambiguate multiple icons it now claims a well-known service name via RequestOwnership():
service_name_ = base::StrCat({"org.freedesktop.StatusNotifierItem-",
PID, "-", service_id_});
Chromium 149 and earlier never requested a well-known name at all; they registered with the connection’s unique name (:1.x), which needs no ownership grant. That is why older Electron snaps worked.
The unity7 template only whitelists ownership of the KDE-spec name:
dbus (bind)
bus=session
name=org.kde.StatusNotifierItem-[0-9]*,
It does not cover org.freedesktop.StatusNotifierItem-*, so under Chromium 152 the snap fails at a new point:
Failed to get the ownership of org.freedesktop.StatusNotifierItem-<PID>-1:
Connection ":1.x" is not allowed to own the service
"org.freedesktop.StatusNotifierItem-<PID>-1" due to AppArmor policy
[...] org.freedesktop.StatusNotifierItem-<PID>-1 is not owned by the bus
The tray icon never appears.
Summary across versions (verified against Chromium git tags and a strict-confined build):
| Chromium |
Electron |
Object path |
Well-known name |
Result under unity7 |
| ≤ 149 |
≤ 42 |
/StatusNotifierItem |
none (unique conn name) |
works |
| 150-151 |
43 |
/org/chromium/StatusNotifierItem/N |
none |
denied (object path) |
| 152+ |
44 |
/StatusNotifierItem |
org.freedesktop.StatusNotifierItem-<PID>-<ID> |
denied (name ownership) |
The unity7 (and/or desktop-legacy) template needs to allow ownership of org.freedesktop.StatusNotifierItem-* (matching the well-known name Chromium 152+ now uses), in addition to the existing org.kde.StatusNotifierItem-[0-9]* rule. Ideally also permit the /org/chromium/StatusNotifierItem/* object path so Chromium 150-151 based apps are covered too. Without this, all Chromium-based snaps (Electron apps, Chromium, Slack, etc.) lose their tray icon on any build newer than Chromium 149.