Works, but doesnt surpress the tray icon window spawned by wine

ToasterUwU commented

2026-05-15 22:47:23 +02:00

Maybe thats out of scope and needs to be somehow done on the Niri side instead, but for now i can conclude that this pogram sadly doesnt fix my issue, only change it.
When i open something via Proton or Wine, it will try to spawn a tray icon of the old protocol. Without this program that spawn a tiny white tray icon as a window, like a separate one. I can simply close it with no issues, but not tray icon remains in that case obviously. With this program it puts the tray icon in the proper bar with the newer protocol, but wine still opens some kind of extra window. Its completely black and auto tiles, has no title or anything identifying about it, and when i close it i get a wine error popup talking about how the explorer.exe expected to have a tray icon bar somewhere but its gone now. This also breaks the tray icon, leaving it in the bar, even after closing the program and all that.

Let me know if there is something i need to do, or this is just a bug.

Maybe thats out of scope and needs to be somehow done on the Niri side instead, but for now i can conclude that this pogram sadly doesnt fix my issue, only change it. When i open something via Proton or Wine, it will try to spawn a tray icon of the old protocol. Without this program that spawn a tiny white tray icon as a window, like a separate one. I can simply close it with no issues, but not tray icon remains in that case obviously. With this program it puts the tray icon in the proper bar with the newer protocol, but wine still opens some kind of extra window. Its completely black and auto tiles, has no title or anything identifying about it, and when i close it i get a wine error popup talking about how the explorer.exe expected to have a tray icon bar somewhere but its gone now. This also breaks the tray icon, leaving it in the bar, even after closing the program and all that. Let me know if there is something i need to do, or this is just a bug.

vikingowl commented

2026-05-16 18:58:01 +02:00

Owner

Hey @ToasterUwU, thanks for the detailed report — sat down with this on a similar setup (Battle.net via Proton, Hyprland rather than Niri) and the picture is clearer.

What it actually is

The black auto-tiling window isn't Wine's explorer.exe systray. It's a top-level X11 helper window the wrapped app itself creates as part of its tray-icon plumbing:

For Qt-based apps (Battle.net's launcher is Qt), it's QTrayIconMessageWindow — on my machine 1914×1048 at (3, 29), _NET_WM_WINDOW_TYPE_NORMAL, program-specified min == max. Qt sizes it to the working area because under traditional X11 the WM is expected to hide or ignore it.
For non-Qt Wine apps it'll be whatever explorer.exe-or-equivalent helper that app spawns — same shape, different title.

On KDE this never surfaces because KWin's X11 handling absorbs these helpers. Hyprland's XWM (and almost certainly Niri's) treats them as normal tiles. So you're partly right that it's compositor-side, but not really a Niri-specific bug — same window class shows up under Hyprland, just nobody noticed because we tolerate one stray tile.

That also matches what you saw on close: Wine/Qt watch that window, expect it to exist for the lifetime of the tray icon, and don't recover gracefully when it disappears — hence the "explorer.exe expected to have a tray icon bar somewhere" error and the broken tray.

Fixing yours specifically

Could you run

xprop WM_CLASS _NET_WM_NAME _NET_WM_PID _NET_WM_WINDOW_TYPE

and click the offending black tile, then paste the output here? With the title + class we can write a Niri window-rule that matches just that helper and pins it somewhere out of sight. Unfortunately it'll be one rule per offending app, since each Wine/Proton app names its helper differently.

On the proxy side

This isn't a regression of xembed-sni-proxy — KDE's upstream xembedsniproxy has the same blind spot for the same reason.

There's a chunk of unpushed work in this repo (orphan-icon rescue on restart, context-menu click injection, popup-menu repositioning) that I'll push soon. None of it addresses the helper-window issue, but the rest may improve your experience.

A proxy-side mitigation is on the table — detect helper top-levels owned by the same PID as a docked tray client and unmap them — but it's risky because Wine watches its windows and reacts badly to unmapping (the same failure you already hit by closing manually). If we go that route it'll be opt-in.

Hey @ToasterUwU, thanks for the detailed report — sat down with this on a similar setup (Battle.net via Proton, Hyprland rather than Niri) and the picture is clearer. **What it actually is** The black auto-tiling window isn't Wine's `explorer.exe` systray. It's a top-level X11 *helper* window the wrapped app itself creates as part of its tray-icon plumbing: - For Qt-based apps (Battle.net's launcher is Qt), it's `QTrayIconMessageWindow` — on my machine 1914×1048 at (3, 29), `_NET_WM_WINDOW_TYPE_NORMAL`, program-specified min == max. Qt sizes it to the working area because under traditional X11 the WM is expected to hide or ignore it. - For non-Qt Wine apps it'll be whatever `explorer.exe`-or-equivalent helper that app spawns — same shape, different title. On KDE this never surfaces because KWin's X11 handling absorbs these helpers. Hyprland's XWM (and almost certainly Niri's) treats them as normal tiles. So you're partly right that it's compositor-side, but not really a Niri-specific bug — same window class shows up under Hyprland, just nobody noticed because we tolerate one stray tile. That also matches what you saw on close: Wine/Qt watch that window, expect it to exist for the lifetime of the tray icon, and don't recover gracefully when it disappears — hence the "explorer.exe expected to have a tray icon bar somewhere" error and the broken tray. **Fixing yours specifically** Could you run ``` xprop WM_CLASS _NET_WM_NAME _NET_WM_PID _NET_WM_WINDOW_TYPE ``` and click the offending black tile, then paste the output here? With the title + class we can write a Niri window-rule that matches just that helper and pins it somewhere out of sight. Unfortunately it'll be one rule per offending app, since each Wine/Proton app names its helper differently. **On the proxy side** This isn't a regression of `xembed-sni-proxy` — KDE's upstream `xembedsniproxy` has the same blind spot for the same reason. There's a chunk of unpushed work in this repo (orphan-icon rescue on restart, context-menu click injection, popup-menu repositioning) that I'll push soon. None of it addresses the helper-window issue, but the rest may improve your experience. A proxy-side mitigation is on the table — detect helper top-levels owned by the same PID as a docked tray client and unmap them — but it's risky because Wine watches its windows and reacts badly to unmapping (the same failure you already hit by closing manually). If we go that route it'll be opt-in.

vikingowl added the bug needs info labels 2026-05-16 19:00:27 +02:00

ToasterUwU commented

2026-05-17 04:21:37 +02:00

Author

Thanks for the detailed response. I understand now what that window is and what its for.
I also while reporting this here reported it on niris side, you can find the related conversation here: https://github.com/niri-wm/niri/issues/2648#issuecomment-4466472872

They say its intended behavior to show it, which i find very weird. It wont ever show anything, it has no interaction purpose at all, its literally just in the way, and its not handled by default at all. So it does nothing useful to the user by being there as an actual tile, and it does get in the way and force users to make their own workaround. That just seems silly as a design choice.

Either way, im gonna look into setting up my own workaround.

Sidenote, im also working on making a package for this program on nixpkgs. I will post a link to the PR when i made one

Thanks for the detailed response. I understand now what that window is and what its for. I also while reporting this here reported it on niris side, you can find the related conversation here: https://github.com/niri-wm/niri/issues/2648#issuecomment-4466472872 They say its intended behavior to show it, which i find very weird. It wont ever show anything, it has no interaction purpose at all, its literally just in the way, and its not handled by default at all. So it does nothing useful to the user by being there as an actual tile, and it does get in the way and force users to make their own workaround. That just seems silly as a design choice. Either way, im gonna look into setting up my own workaround. Sidenote, im also working on making a package for this program on nixpkgs. I will post a link to the PR when i made one

ToasterUwU commented

2026-05-17 05:12:35 +02:00

Author

I just found another standalone tool like this that seemingly solved the black window issue?
https://github.com/waliori/wine-sni-bridge/

I just found another standalone tool like this that seemingly solved the black window issue? https://github.com/waliori/wine-sni-bridge/

ToasterUwU commented

2026-05-17 05:36:18 +02:00

Author

I tried that one.. and its.. not working well under Niri at least. Still shows a black window, doesnt do the tray icon correctly either. It runs, but it certainly does not do what it should.

Works, but doesnt surpress the tray icon window spawned by wine #1