JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 07:15:19 +01:00

[GH-ISSUE #1440] Tray icons become unresponsive after some time #3251

New issue

Open

opened 2026-05-22 23:55:02 +01:00 by JakeStanger · 4 comments

JakeStanger commented

2026-05-22 23:55:02 +01:00

Owner

Originally created by @Kirottu on GitHub (Apr 4, 2026).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1440

Describe the bug

All tray icons will become static and unresponsive after some time. The actions performed in the icons do not happen, the icons do not disappear when apps close nor do any visual updates happen either. They are just frozen in time.

The issue #1433 seems to describe the same issue, and while yes a reboot or an ironbar restart fixes it temporarily, it happens to me consistently enough for it to be an issue (my devices stay on for long periods of time, so even if the issue takes hours or days to manifest it will eventually happen).

My logs are also filled with loads of log lines for WARN system_tray::client: 459: Error getting IconName: ZBusFdo(Failed("error occurred in Get")) and WARN system_tray::client: 469: org.freedesktop.DBus.Error.InvalidArgs: No such property “IconPixmap”. Those seem possibly relevant.

To reproduce
Not quite sure what makes it happen, it just kind of does after a while of running. The tray icons I regularly have:
Steam, Nextcloud, Mullvad VPN, nm-applet, Mumble, Equibop, blueman-applet. The only really notable detail I can think of is that the Mullvad VPN tray icon animates when toggling the connection state.

Expected behavior

Tray icons stay functional.

System information:

Distro: NixOS unstable (2026-04-04)
Compositor: niri
Ironbar version: 0.19.0-pre (2026-04-01)

Configuration

Config

{
  "center": [
    {
      "type": "clock"
    }
  ],
  "end": [
    {
      "type": "tray"
    }
  ],
  "height": 50,
  "margin": {
    "bottom": 10,
    "left": 10,
    "right": 10,
    "top": 10
  },
  "name": "bar",
  "position": "top",
  "start": [
    {
      "name_map": {
        "chat": "󰭹",
        "games": "󰸻",
        "vr": "󰢔",
        "web-dp1": "󰖟",
        "web-dp2": "󰖟",
        "web-dp3": "󰖟"
      },
      "sort": "index",
      "type": "workspaces"
    }
  ],
  "start_hidden": true
}

Originally created by @Kirottu on GitHub (Apr 4, 2026). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1440 **Describe the bug**  All tray icons will become static and unresponsive after some time. The actions performed in the icons do not happen, the icons do not disappear when apps close nor do any visual updates happen either. They are just frozen in time. The issue #1433 seems to describe the same issue, and while yes a reboot or an ironbar restart fixes it temporarily, it happens to me consistently enough for it to be an issue (my devices stay on for long periods of time, so even if the issue takes hours or days to manifest it will eventually happen). My logs are also filled with loads of log lines for `WARN system_tray::client: 459: Error getting IconName: ZBusFdo(Failed("error occurred in Get"))` and `WARN system_tray::client: 469: org.freedesktop.DBus.Error.InvalidArgs: No such property “IconPixmap”`. Those seem possibly relevant. **To reproduce** Not quite sure what makes it happen, it just kind of does after a while of running. The tray icons I regularly have: Steam, Nextcloud, Mullvad VPN, nm-applet, Mumble, Equibop, blueman-applet. The only really notable detail I can think of is that the Mullvad VPN tray icon animates when toggling the connection state. **Expected behavior**  Tray icons stay functional. **System information:** - Distro: NixOS unstable (2026-04-04) - Compositor: niri - Ironbar version: 0.19.0-pre (2026-04-01) **Configuration**  <details><summary>Config</summary> ```json { "center": [ { "type": "clock" } ], "end": [ { "type": "tray" } ], "height": 50, "margin": { "bottom": 10, "left": 10, "right": 10, "top": 10 }, "name": "bar", "position": "top", "start": [ { "name_map": { "chat": "󰭹", "games": "󰸻", "vr": "󰢔", "web-dp1": "󰖟", "web-dp2": "󰖟", "web-dp3": "󰖟" }, "sort": "index", "type": "workspaces" } ], "start_hidden": true } ``` </details>

JakeStanger added the

labels

2026-05-22 23:55:02 +01:00

JakeStanger commented

2026-05-22 23:55:02 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 21, 2026):

Do you usually put said device(s) to sleep/hibernate, or have their screens turn off/disconnect, or anything else similar? I'm wondering if there's some event causing a bar to disconnect from dbus.

@JakeStanger commented on GitHub (Apr 21, 2026): Do you usually put said device(s) to sleep/hibernate, or have their screens turn off/disconnect, or anything else similar? I'm wondering if there's some event causing a bar to disconnect from dbus.

JakeStanger commented

2026-05-22 23:55:02 +01:00

Author

Owner

@Kirottu commented on GitHub (Apr 22, 2026):

Both, I tend to suspend my desktop almost always instead of shutting it down, and I also have a script that disables my main monitors and enables a TV for media PC use.

@Kirottu commented on GitHub (Apr 22, 2026): Both, I tend to suspend my desktop almost always instead of shutting it down, and I also have a script that disables my main monitors and enables a TV for media PC use.

JakeStanger commented

2026-05-22 23:55:02 +01:00

Author

Owner

@jmickelin commented on GitHub (May 4, 2026):

Since you're using NixOS, which installs the Plasma desktop by default, is it possible you are getting hit by this issue? https://github.com/Alexays/Waybar/issues/3468#issuecomment-2262074645

In Waybar this race condition causes the whole tray module to disappear, but it doesn't sound implausible that it would manifest differently in Ironbar.

What does it say if you run busctl --user status org.kde.StatusNotifierWatcher while the tray is acting up?

@jmickelin commented on GitHub (May 4, 2026): Since you're using NixOS, which installs the Plasma desktop by default, is it possible you are getting hit by this issue? https://github.com/Alexays/Waybar/issues/3468#issuecomment-2262074645 In Waybar this race condition causes the whole tray module to disappear, but it doesn't sound implausible that it would manifest differently in Ironbar. What does it say if you run `busctl --user status org.kde.StatusNotifierWatcher` while the tray is acting up?

JakeStanger commented

2026-05-22 23:55:02 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 17, 2026):

I've tried a few things to replicate this with no luck. Since it doesn't seem to be a prevalent issue & I've not heard anything back, I'm removing this from the current milestone.

If you get any more information on this let me know and I'll look to address it.

@JakeStanger commented on GitHub (May 17, 2026): I've tried a few things to replicate this with no luck. Since it doesn't seem to be a prevalent issue & I've not heard anything back, I'm removing this from the current milestone. If you get any more information on this let me know and I'll look to address it.