Unity Editor keyboard input broken — WM_TAKE_FOCUS focus regression in transient popups

[Jurgencotting]

⚠️ Disclaimer: I'm sorry in advance — this text was written with the help of AI
(Claude) because I'm not very experienced with programming, I don't fully understand
all the technical details involved, and my English is quite poor. But I spent a lot
of time testing this and wanted to report it as accurately as possible. Please bear
with me! 🙏

---

Summary

Unity Editor has persistent keyboard input issues when running under xwayland-satellite.
I'm aware this is related to the already open issues
#278 and
#286, but I wanted to
share additional A/B testing results around
PR #397 that may help
narrow down the root cause, and ask if there's a known path forward.

I also opened a discussion on the Niri side:
niri-wm/niri#4232

---

Environment

• Compositor: Niri (latest stable)
• XWayland bridge: xwayland-satellite (built from latest main + tested PR Fix: unity editor add component pop up #397)
• GPU: NVIDIA GTX 1650 Mobile (PRIME offload, drivers 595.58.03)
• OS: CachyOS (Arch-based), Fish shell
• Unity version: Unity Editor 2022.x and 6000.x (both affected)

---

Symptoms

Consistently reproducible:

1. "Add Component" search box — popup opens but keyboard input is completely
   ignored. The parent editor window seems to reclaim focus as soon as typing begins.

2. Asset renaming (Project panel) — double-clicking to rename shows the text
   field, but no input is registered.

3. Unity Hub — occasional focus issues in the launcher itself.

These issues do not occur in:

• Native X11 sessions (TTY-based startx)
• Compositors with integrated wlroots XWayland (Hyprland, MangoWM, Sway)

---

A/B testing with PR #397

I tested PR #397, which
targets the WM_TAKE_FOCUS popup focus logic. Results:

Behavior	Without PR #397	With PR #397
"Add Component" typing	❌ Broken	✅ Fixed
Asset renaming (Project panel)	❌ Broken	❌ Still broken
Steam client hover/interaction	✅ Working	❌ Regressed

PR #397 fixes one input path but breaks Steam hover events. This suggests that
WM_TAKE_FOCUS handling is more nuanced than a single patch can cover — different
applications seem to depend on conflicting focus behaviors for transient windows.

---

Additional context from issue #278

As reported in #278, a community build
(WMsans/xwayland-satellite fix/unity-editor)
gets the "Add Component" popup working. However, as noted in that thread, the fix is
not considered proper since it can break input focus on toplevel windows.

The xprop output from #278 for the broken popup shows:

• _NET_WM_WINDOW_TYPE_POPUP_MENU
• WM_PROTOCOLS: WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_SYNC_REQUEST
• WM_TRANSIENT_FOR pointing to the parent editor window

This confirms the popup is a transient that requests focus via WM_TAKE_FOCUS
but the parent window appears to be reclaiming focus before input is registered.

There's also a ConfigureRequest with STACK_MODE = Above happening on popup open,
as noted in #278 — raising the window does not help; only granting input focus does.

---

What I've tried

Workaround	Result
TTY startx X11 session	✅ Everything works — confirms Wayland/XWayland issue
cage nested compositor	❌ Same keyboard issue
Various _NET_WM focus hint overrides	❌ No effect
Building PR #397	✅ Partial fix (Add Component), ❌ Steam regression
Switching to MangoWM (integrated wlroots XWayland)	✅ Unity works fully

---

Question

Is there a correct fix being considered for WM_TAKE_FOCUS on transient/popup
windows that wouldn't regress other applications like Steam?

The core behavior needed seems to be: when a WM_TAKE_FOCUS transient popup opens
(with STACK_MODE Above in the ConfigureRequest), xwayland-satellite should grant
keyboard focus to the transient, not the parent — but only for popups of this type,
so that Steam and other apps don't lose their hover behavior.

I'm happy to test patches, provide WAYLAND_DEBUG or RUST_LOG=debug logs, or
reproduce specific scenarios on demand. Thank you for the incredible work on
xwayland-satellite! 💙