[GH-ISSUE #791] Tray with libdbusmenu-gtk3 is buggy #3059

New issue

Closed

opened 2026-05-22 23:53:46 +01:00 by JakeStanger · 4 comments

JakeStanger commented

2026-05-22 23:53:46 +01:00

Owner

Originally created by @freijon on GitHub (Nov 25, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/791

Describe the bug
I'm upgrading the Gentoo package to the new version but I've noticed that the tray behaves strangely. When I click the tray icon then most of the time, nothing happens. I have these warnings/errors in the stdout:

2024-11-25T05:06:30.093663Z WARN GTK: 112: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2024-11-25T05:06:32.540958Z ERROR GTK: 111: [LIBDBUSMENU-GLIB] CRITICAL: dbusmenu_menuitem_send_about_to_show: assertion 'DBUSMENU_IS_MENUITEM(mi)' failed

But on other times it works fine and the menu is shown. Sometimes it also works once and then stops working.

To Reproduce
Steps to reproduce the behavior:

Click on a tray icon (I'm using the one from Steam)
Nothing happens
Check the stdout

Expected behavior
The menu opens all the time.

System information:

Distro: Gentoo
Compositor: niri
Ironbar version: 0.16.1

Originally created by @freijon on GitHub (Nov 25, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/791 **Describe the bug** I'm upgrading the Gentoo package to the new version but I've noticed that the tray behaves strangely. When I click the tray icon then most of the time, nothing happens. I have these warnings/errors in the stdout: > 2024-11-25T05:06:30.093663Z WARN GTK: 112: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2024-11-25T05:06:32.540958Z ERROR GTK: 111: [LIBDBUSMENU-GLIB] CRITICAL: dbusmenu_menuitem_send_about_to_show: assertion 'DBUSMENU_IS_MENUITEM(mi)' failed But on other times it works fine and the menu is shown. Sometimes it also works once and then stops working. **To Reproduce** Steps to reproduce the behavior: 1. Click on a tray icon (I'm using the one from Steam) 2. Nothing happens 3. Check the stdout **Expected behavior** The menu opens all the time. **System information:** - Distro: Gentoo - Compositor: niri - Ironbar version: 0.16.1

JakeStanger

2026-05-22 23:53:46 +01:00

closed this issue
added the
T:Bug

P:Medium

A:Client

M:Tray
labels

JakeStanger commented

2026-05-22 23:53:47 +01:00

Author

Owner

@JakeStanger commented on GitHub (Nov 25, 2024):

It seems odd that'd be tempermental, but this to me reads like an environmental issue. Perhaps a race condition between Ironbar starting and your dbus session (env vars) loading. There have been other Niri-specific tray issues recently too.

Are you able to confirm if this is still an issue for yourself on another compositor please?

@JakeStanger commented on GitHub (Nov 25, 2024): It seems odd that'd be tempermental, but this to me reads like an environmental issue. Perhaps a race condition between Ironbar starting and your dbus session (env vars) loading. There have been other Niri-specific tray issues recently too. Are you able to confirm if this is still an issue for yourself on another compositor please?

JakeStanger commented

2026-05-22 23:53:47 +01:00

Author

Owner

@freijon commented on GitHub (Nov 25, 2024):

Interesting thought!
I gave it a try with Hyprland. Observations:

The warning message from my initial post is always there and apparently has nothing to do with the issue
At first, I was not able to reproduce the issue. But it seems when I kill ironbar, freshly start it and directly go for the tray menu, it will fail. The error message was the same on Hyprland
After ironbar is running for a while, it seems the tray menu fixes itself and it starts working (permanently?). This is where it seems niri behaves differently than Hyprland. With niri it felt like on/off randomly whereas in Hyprland it was first off, then on

P.S. with 0.16.0 I had no such issues

@freijon commented on GitHub (Nov 25, 2024): Interesting thought! I gave it a try with `Hyprland`. Observations: - The warning message from my initial post is always there and apparently has nothing to do with the issue - At first, I was not able to reproduce the issue. But it seems when I kill `ironbar`, freshly start it and directly go for the tray menu, it will fail. The error message was the same on `Hyprland` - After `ironbar` is running for a while, it seems the tray menu fixes itself and it starts working (permanently?). This is where it seems `niri` behaves differently than `Hyprland`. With `niri` it felt like on/off randomly whereas in `Hyprland` it was first off, then on P.S. with 0.16.0 I had no such issues

JakeStanger commented

2026-05-22 23:53:47 +01:00

Author

Owner

@quietvoid commented on GitHub (Nov 30, 2024):

On Sway I often get issues when turning my monitors back on.
For the tray it happens that old apps are still shown and I have to reopen ironbar.

@quietvoid commented on GitHub (Nov 30, 2024): On Sway I often get issues when turning my monitors back on. For the tray it happens that old apps are still shown and I have to reopen ironbar.

JakeStanger commented

2026-05-22 23:53:47 +01:00

Author

Owner

@JakeStanger commented on GitHub (Sep 18, 2025):

I think I've managed to catch this, after spending far too long debugging the GTK 4 port before realising it was this bug.

The tray client sent menu connect events to the first tray module to connect, but then didn't re-send those for others. The result of this was that the menus would work correctly on one (somewhat random) bar, but not others. The linked PR ensures the events are properly sent to all tray module instances.

I'm going to close this issue when I merge the PR, but if you do still have issues I'll re-open for now. If it is something different, I probably won't fix it on the GTK 3 version as the GTK 4 branch is nearing completion and won't use libdbusmenu-gtk3.

@JakeStanger commented on GitHub (Sep 18, 2025): I *think* I've managed to catch this, after spending far too long debugging the GTK 4 port before realising it was this bug. The tray client sent menu connect events to the first tray module to connect, but then didn't re-send those for others. The result of this was that the menus would work correctly on one (somewhat random) bar, but not others. The linked PR ensures the events are properly sent to all tray module instances. I'm going to close this issue when I merge the PR, but if you do still have issues I'll re-open for now. If it is something different, I probably won't fix it on the GTK 3 version as the GTK 4 branch is nearing completion and won't use `libdbusmenu-gtk3`.