Bug: Rift doesn't respect focus-change with mouse

[hajiboy95]

Bug Description

When changing window focus using the mouse by clicking a window, Rift's layout engine selection does not update to match the active window.

Consequently, when a layout mutation shortcut is triggered (such as MoveNode, SwapWindows, or PromoteToMaster), the layout command operates on the last window focused via keyboard shortcuts, rather than the window currently focused by the mouse.

Steps to Reproduce

This works the best with the stack-layout since here it's obvious which window is holding the focus

1. Focus Window A using a keyboard shortcut (e.g. FocusWindow).
2. Move the mouse to Window B and click it. Window B is now physically focused and active.
3. Press a layout movement shortcut (e.g., MoveNode or SwapWindows).
4. Observe: Window A (the last keyboard-focused window) is moved instead of Window B. In some configurations, focus may also forcibly snap back to Window A.

---

Desired Solution

• Synchronize Selection on Focus Change: Ensure that any change in window focus (including mouse clicks and hover events) immediately updates the layout engine's selection state (select_window in the active workspace tree).
• Robust Target Resolution: When executing a layout command, the layout engine should verify and resolve the target window using the actual active window or the window physically under the cursor, keeping the focus and layout state in sync.

[hajiboy95]

Here a first analysis what might be the reason. Written by my agent, just brielfy checked it. No guarantee that this might be the reason but maybe a good first indication

Technical Analysis & Root Cause

1. Selection Sync Mismatch

• Keyboard-driven focus commands (e.g. FocusWindow) explicitly update the layout engine's selection state via apply_focus_response and select_window.
• Mouse-driven focus changes (clicks or hovers) change the active window in macOS. However, the layout engine's internal selection state (tracked via the workspace tree's selection nodes) is not updated, keeping it out of sync.
• When a layout command is subsequently run, it resolves the target window using the layout engine's selection state, which still points to the old keyboard-focused window.

2. Focus Snap-Back

Because the physical macOS focus (the mouse-focused window) is different from the layout engine's internal selection (the keyboard-focused window), triggering layout re-renders or cursor-following actions can cause the focus/cursor to forcibly snap back to the old keyboard-focused window. This makes it clear that the layout engine has failed to track the focus transition correctly.

[Swoorup]

This appears to have been broken recently.

[FandaGong]

I often get windows that are non-responsive to floating/moving to another space, and tiling areas where there is no window but rift thinks there is. Sometimes when a window is focused, the actions done on that window are applied to another. Started occuring recently too. Could this issue be related?

[hajiboy95]

@FandaGong indeed this seems related

Indeed I have some windows which aren't detected by rift anymore too. Currently my work around is destroying that window (e.g. by closing) and re open it. Happens a lot to specific applications and often after sleep. e.g. for zen and telegram.

This one i can actually reproduce
Steps:

• Hide Zen browser
• start rift
• open zen browser
• see zen browser is floating

I fixed a lot of that trouble with my PR #400

Let's hope it'll get merged soon

[sj-cstar]

Something has fundamentally broken in the last few changes :/

Asides from this issue, it no longer appears to remember the layout of windows within the workspace. Fullscreening the window and back appears to bork the layout in traditional view.

It appears to lose windows, and keep ghost windows longer than necessary.

[acsandmann]

Something has fundamentally broken in the last few changes :/

Asides from this issue, it no longer appears to remember the layout of windows within the workspace. Fullscreening the window and back appears to bork the layout in traditional view.

It appears to lose windows, and keep ghost windows longer than necessary.

what version/branch?

[sj-cstar]

Something has fundamentally broken in the last few changes :/
Asides from this issue, it no longer appears to remember the layout of windows within the workspace. Fullscreening the window and back appears to bork the layout in traditional view.
It appears to lose windows, and keep ghost windows longer than necessary.

what version/branch?

Pretty much the current tip of the branch: 223c3dc