njspam
September 23, 2026, 5:45am
1
Hi,
Could you please update the electron version used to fix this bug?
I believe 18 Sep build still ships 43.4.0 so needs to go to 43.5.0+
opened 04:36AM - 06 Aug 26 UTC
closed 06:13PM - 31 Aug 26 UTC
platform/linux
bug
43-x-y
### Preflight Checklist
- [x] I have read the [Contributing Guidelines](https:/… /github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.
### Electron Version
43.3
### What operating system(s) are you using?
Other Linux
### Operating System Version
CachyOS 7.1.6-1, GNOME 50.4 (Wayland)
### What arch are you using?
x64
### Last Known Working Electron version
43.2
### Does the issue also appear in Chromium / Google Chrome?
I don't know how to test
### Expected Behavior
icon should appear on the top right through libappindicator when it is launched (and provides one)
### Actual Behavior
three dots appear on the right side and the icon never loads
<img width="45" height="34" alt="Image" src="https://github.com/user-attachments/assets/d937c11e-3fea-45f2-875b-a9f26a367c53" />
### Testcase Gist URL
_No response_
### Additional Information
Upgrading from Electron 43.2.x to 43.3.0 causes AppIndicator/StatusNotifierItem tray icons to disappear on GNOME 50.4 (Wayland).
This has been reproduced with at least Caprine and youtube-music-desktop-app by launching the app.asar with electron directly.
Electron 43.2 works correctly for both applications when doing the same thing.
The app registers a org.freedesktop.StatusNotifierItem-* D-Bus name, but /StatusNotifierItem exports no interfaces:
```busctl --user introspect \
org.freedesktop.StatusNotifierItem-XXXXX-1 \
/StatusNotifierItem
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
```
and running
`gdbus introspect --session --dest org.freedesktop.StatusNotifierItem-XXXXX-1 --object-path /StatusNotifierItem
`
returns the following:
```
node /StatusNotifierItem {
};
```
Downgrading to Electron 43.2 through electron43-bin in the AUR restores normal tray icon behavior.
43-x-y ← fix-linux-tray-registration-43-x-y
opened 07:50PM - 26 Aug 26 UTC
#### Description of Change
Fixes https://github.com/electron/electron/issues/53… 213
#52952 cherry-picked https://crrev.com/c/8250459, which gives each status icon its own object path and passes `"<well-known name>/StatusNotifierItem/<n>"` to `RegisterStatusNotifierItem`. GNOME's appindicator extension (and other GDBusProxy-based hosts) treat an argument that doesn't start with `/` as a bus name; resolving that string fails, the registration is refused, and the icon falls back to XEmbed on Xorg and disappears on Wayland. Upstream fixed this in https://crrev.com/c/8272040 (Chromium 154.0.8016.0, already in `main`): the first icon uses the shared session bus and later ones a private connection, the item is exported at `/StatusNotifierItem` again, and only the well-known name is registered. This picks that CL (production hunks only, as with the earlier two) directly after `cherry-pick-726eafecc145.patch`, and rebases `fix_linux_tray_id.patch` onto the resulting constructor, which now matches `main`'s copy of that patch.
Checked with a stand-in `org.kde.StatusNotifierWatcher` that resolves items the way the GNOME extension does: 43.4.1 registers `org.freedesktop.StatusNotifierItem-<pid>-1/StatusNotifierItem/1` and is refused with `NameHasNoOwner`; the 44-x-y build of the same change (#53214) registers `org.freedesktop.StatusNotifierItem-<pid>-1` and the `Id` property reads back on both the `org.kde` and `org.freedesktop` interfaces at `/StatusNotifierItem`. On Ubuntu 24.04 GNOME Wayland (arm64) the same build shows the icon in the top bar with a working menu and `RegisteredStatusNotifierItems` lists it, where 44.0.0 lists nothing.
#### Checklist
- [x] PR description included
- [x] I have built and tested this change
- [x] [I have reviewed and verified the changes](https://github.com/electron/governance/blob/main/policy/ai.md)
#### Release Notes
Notes: Fixed the tray icon not appearing on GNOME (and disappearing entirely on Wayland) since 43.4.1.
44-x-y ← fix-linux-tray-registration-44-x-y
opened 07:50PM - 26 Aug 26 UTC
#### Description of Change
Fixes https://github.com/electron/electron/issues/53… 213
#52951 cherry-picked https://crrev.com/c/8250459, which gives each status icon its own object path and passes `"<well-known name>/StatusNotifierItem/<n>"` to `RegisterStatusNotifierItem`. GNOME's appindicator extension (and other GDBusProxy-based hosts) treat an argument that doesn't start with `/` as a bus name; resolving that string fails, the registration is refused, and the icon falls back to XEmbed on Xorg and disappears on Wayland. Upstream fixed this in https://crrev.com/c/8272040 (Chromium 154.0.8016.0, already in `main`): the first icon uses the shared session bus and later ones a private connection, the item is exported at `/StatusNotifierItem` again, and only the well-known name is registered. This picks that CL (production hunks only, as with the earlier two) directly after `cherry-pick-726eafecc145.patch`, and rebases `fix_linux_tray_id.patch` onto the resulting constructor, which now matches `main`'s copy of that patch.
Checked with a stand-in `org.kde.StatusNotifierWatcher` that resolves items the way the GNOME extension does: 44.0.0-beta.6 / 44.0.0 registers `org.freedesktop.StatusNotifierItem-<pid>-1/StatusNotifierItem/1` and is refused with `NameHasNoOwner`; the linux-x64 CI build of this PR registers `org.freedesktop.StatusNotifierItem-<pid>-1` and the `Id` property reads back on both the `org.kde` and `org.freedesktop` interfaces at `/StatusNotifierItem`. On Ubuntu 24.04 GNOME Wayland (arm64) the same build shows the icon in the top bar with a working menu and `RegisteredStatusNotifierItems` lists it, where 44.0.0 lists nothing.
#### Checklist
- [x] PR description included
- [x] I have built and tested this change
- [x] [I have reviewed and verified the changes](https://github.com/electron/governance/blob/main/policy/ai.md)
#### Release Notes
Notes: Fixed the tray icon not appearing on GNOME (and disappearing entirely on Wayland) since 44.0.0-beta.6.
opened 05:35PM - 19 Aug 26 UTC
closed 05:26AM - 20 Aug 26 UTC
platform/linux
bug
has-repro-gist
43-x-y
### Preflight Checklist
- [x] I have read the [Contributing Guidelines](https:/… /github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.
### Electron Version
43.4.1
### What operating system(s) are you using?
Other Linux
### Operating System Version
Linux DamgladorPC 6.18.44-1-lts #1 SMP PREEMPT_DYNAMIC Tue, 11 Aug 2026 21:10:19 +0000 x86_64 GNU/Linux DE: KDE Plasma (Wayland)
### What arch are you using?
x64
### Last Known Working Electron version
43.4.0
### Does the issue also appear in Chromium / Google Chrome?
I don't know how to test
### Expected Behavior
Tray icon should appear whether an app is launched with generic Electron or bundled.
### Actual Behavior
Apps have tray icons if they're launched with bundled electron, but not when they're launched with a generic electron build.
### Testcase Gist URL
https://gist.github.com/Damglador/4c7a647a3465de5b7933bc32d7c2dd92
### Additional Information
The testcase gist code is generated by Claude.
Upstream Chromium bug - Chromium
Cheers,
Hi @njspam
We’ve already upgraded to Electron 44.4.2 (Chromium 152), which is well beyond 43.5.0. The upgrade is merged and will be part of the next Lens release.
1 Like
Hi @njspam , quick update — 2026.10.51501-latest is out and includes the Electron 44 update. It’s rolling out gradually; you can download it from Download — Lens .
Thanks again for raising it.
njspam
October 8, 2026, 5:55am
4
Got it! Thank you for doing it.