XWayland windows are never released: destroyed and unmapped X windows stay in the window list and keep focus

[tomocrafter]

Summary

ShojiWM keeps XWayland toplevels in its managed window list forever. Windows are retained both when the X window is merely unmapped and when the client process exits entirely. COMPOSITOR.event.onClose never fires for them, so config-side cleanup (HYBRID_WINDOW_MANAGER.onClose in the default config) is never invoked.

The retained windows also keep isFocused === true, so multiple windows report focus simultaneously. This corrupts the window stack and focus handling for all windows, including native Wayland ones.

Environment

ShojiWM	387436b9e3ed (source install via dist/install.sh)
xwayland-satellite	0.8.2
xorg-xwayland	24.1.13
wayland / mesa	1.25.0 / 26.1.6
Kernel	7.1.4 (Arch, MacBookPro16,2 / T2)
GPU	Intel Iris Plus Graphics G7 (ICL GT2), i915
rustc	1.97.1
Output	eDP-1, 2560x1600, scale: 1.8

Reproduction

1. Start a ShojiWM session.
2. Launch Steam (any app that creates many short-lived X windows works; Steam is convenient because it creates a login dialog, notification toasts, dropdown menus and a Shutdown window).
3. Quit Steam completely and confirm no processes remain: pgrep -c steam → 0.
4. Query the compositor over the config's IPC socket:

import json, os, socket
p = f"{os.environ['XDG_RUNTIME_DIR']}/shojiwm-{os.environ['WAYLAND_DISPLAY']}.sock"
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM); s.connect(p)
s.sendall(b'{"id":1,"method":"workspaces.get"}\n')
buf = b""
while b"\n" not in buf: buf += s.recv(65536)
print(json.dumps(json.loads(buf.decode().splitlines()[0])["result"], indent=2))

Observed

With zero Steam processes alive, the compositor still reports 14 windows, 13 of them steam, and four of them focused at once:

total: 14   focused=true: 4
  0x0   com.mitchellh.ghostty  focused=True   (the only real window)
  0xc   steam                  focused=True   Steam
  0x11  steam                  focused=False
  0x12  steam                  focused=False
  0x13  steam                  focused=True
  0x14 … 0x1b  steam           focused=False
  0x1c  steam                  focused=True   Shutdown

Cross-checking the X server at the same moment — only one window is actually viewable:

IsViewable:  1
IsUnMapped: 19
_NET_CLIENT_LIST entries: 1

So the compositor holds 14 windows where X has 1 mapped toplevel.

The same retention happens while the client is alive: Steam keeps its login dialog and toasts around unmapped, and those are counted as managed, focusable windows too.

Expected

• An XWayland window that is unmapped or whose client has exited should be removed from the managed window list, and COMPOSITOR.event.onClose should fire for it.
• At most one window should have isFocused === true.

Impact

Everything below traces back to this single cause:

• Focus and stacking break for unrelated windows. With several windows reporting focus, Workspace.focusedWindow() in the default config (this.windows.find(w => read(w.isFocused))) returns the first match, which is usually a dead XWayland window. A newly focused window is not raised, so a stale window stays visually on top. This affects native Wayland clients too — e.g. focusing Brave leaves a Ghostty window rendered above it.
• Alt+Tab / window switchers are unusable, since the window list is mostly invisible entries.
• Steam is effectively unusable. Its dropdown menus, tooltips and notification toasts each become decorated toplevels. They also accumulate, so the list grows on every interaction.
• Ghost windows can only be cleared by restarting the compositor; a config hot reload does not drop them.

Notes

• The default config's wiring looks correct — COMPOSITOR.event.onClose((window) => HYBRID_WINDOW_MANAGER.onClose(window)) is present and onClose removes the window from windowStack and every workspace. The event simply never arrives for these windows, which points at the compositor/xwayland-satellite integration rather than the config.
• Steam does not set a useful _NET_WM_WINDOW_TYPE on its menus/toasts (they report _NET_WM_WINDOW_TYPE_NORMAL, and the toasts are override-redirect and absent from _NET_CLIENT_LIST), so type hints alone are not enough to filter them — the unmap/destroy path is what needs fixing.
• Possibly related, but filed separately if you'd prefer: under scale: 1.8, Steam creates its main window at 2512x1484 while the XWayland screen is 1422x889 (the logical size), making it larger than the display and offsetting input coordinates. STEAM_FORCE_DESKTOPUI_SCALING=1 and Xft.dpi: 96 have no effect. xrandr reports the output as 0mm x 0mm.

[bea4dev]

Strangely, I can’t reproduce the issue in my environment.
There may be something hidden in the configuration that is causing the problem.
Would you be able to share your config? Alternatively, could you try adding a log inside COMPOSITOR.event.onClose(...), something like console.log("close : ", window.appId());?

[tomocrafter]

@bea4dev thank you for looking for it. I tried to log it with COMPOSITOR.event.onClose but it never called when i closed steam by its context menu in app bar.

[bea4dev]

@tomocrafter
As I also mentioned on Discord, if Steam windows look blurry with fractional scaling, there is a chance that xwayland-satellite is not working properly.
If xwayland-satellite is working correctly, applications running through XWayland should be displayed without blur, and events should be handled properly.
Please check that.

[bea4dev]

Additionally, if xwayland-satellite has started correctly, you should see a log showing that the display variable was assigned, like this:

2026-08-04T14:44:50.948698Z  INFO shoji_wm::state: xwayland-satellite started, DISPLAY exported display=:0

[tomocrafter]

Found it — and you were right that xwayland-satellite was not working. It never started at all, so everything I reported was happening on the built-in XWayland fallback path.

~/shoji_wm/logs/latest.log has the whole story:

2026-08-04T07:57:24.291132Z  WARN shoji_wm::state: failed to start xwayland-satellite, falling back to built-in XWayland error=Os { code: 98, kind: AddrInUse, message: "Address already in use" }
2026-08-04T07:57:24.291696Z  WARN smithay::xwayland::x11_sockets: Failed to create sockets: Address already in use (os error 98) display=0
2026-08-04T07:57:24.291715Z  WARN smithay::xwayland::x11_sockets: Failed to remove X11 socket error=Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }
2026-08-04T07:57:24.299146Z  INFO shoji_wm::state: XWayland spawned, DISPLAY exported display=1

Cause

Display :0 was already taken, by SDDM's X11 greeter:

$ sudo fuser -v /tmp/.X11-unix/X0
                     USER        PID ACCESS COMMAND
/tmp/.X11-unix/X0:   root        529 F.... Xorg

$ ps -p 529 -o cmd=
/usr/lib/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_...

SDDM's DisplayServer defaults to x11, and that greeter Xorg stays alive for the whole session holding /tmp/.X11-unix/X0. Because the socket is owned by root, ShojiWM cannot remove it either (PermissionDenied), so xwayland-satellite can never bind :0 and the fallback silently takes over on :1.

/tmp/.X11-unix itself is fine (drwxrwxrwt root:root, sticky bit set, writable), and /usr/bin/xwayland-satellite --test-listenfd-support exits 0, so the pre-flight checks all pass — it is purely the :0 collision.

I have now set DisplayServer=wayland in /etc/sddm.conf.d/ and will report back after re-logging in whether the window-lifecycle problems disappear on the satellite path.

Two suggestions regardless of my result

1. The fallback is effectively invisible. Under SDDM, the compositor's stdout goes to /dev/null and only stderr reaches ~/.local/share/sddm/wayland-session.log, so this WARN is only discoverable if you know ~/shoji_wm/logs/latest.log exists. Since the docs describe xwayland-satellite as required, silently degrading to a different XWayland implementation is surprising. Surfacing it more loudly — or making it opt-in rather than automatic — would have saved a lot of digging here. This is probably also why you could not reproduce: anyone whose :0 is free never takes this path.

2. The built-in XWayland fallback still looks buggy and is worth a look on its own, since it is what users land on when satellite fails. On that path, X windows are never released: with Steam fully exited (pgrep -c steam → 0) the compositor still reported 14 windows, 13 of them steam, four of them with focused == true simultaneously, while X had exactly one viewable window. COMPOSITOR.event.onClose never fires for them (verified with console.log in the handler, as you suggested).

Happy to split (2) into its own issue if you would rather keep this one focused on the satellite startup problem.

[bea4dev]

Thank you.
Regarding point 1, I agree that silently degrading is not a very good experience. At the very least, this should probably be shown as a warning.
That said, ShojiWM is designed around the assumption that xwayland-satellite is being used, so point 2 should naturally be fixed once satellite starts correctly. In other words, the actual problem in this issue is essentially all narrowed down to the DISPLAY=:0 collision.
I’ll try making a fix later to avoid that collision.

[bea4dev]

@tomocrafter
fixed!
It’s difficult for me to debug this properly because SDDM does not work correctly in my environment, so please try it out and let me know the result.

[bea4dev]

@tomocrafter
remind

[tomocrafter]

@bea4dev first, thank you for quick response and fixing it! im sorry that its taking long time to confirm if its fixed with that release.
the macbook i was testing shojiwm on it is not in my hand currently so please expect it will take few more days.