fix: insert_feedback overlay (red rectangle) gets stuck on screen during window destroy

[rni34]

Bug

The insert feedback overlay (the colored rectangle showing drop targets during modifier+drag) can get stuck on screen permanently. Reproducible by slowly merging Chrome tabs while using modifier+drag — the red overlay persists until yabai is restarted.

Root Cause

Three issues in event_loop.c:

1. Use-after-free in WINDOW_DESTROYED / APPLICATION_TERMINATED (main bug)

Feedback cleanup runs AFTER space_manager_untile_window → view_remove_window_node, but that function frees BSP tree nodes. When the destroyed window is a sibling of the feedback target node in the BSP tree, the target node is freed first, leaving feedback_node as a dangling pointer. The SLSReleaseWindow call then operates on freed memory and silently fails, leaking the SkyLight window.

2. Missing cleanup in MOUSE_UP error paths

When the drag ends through error paths (window became invalid, went fullscreen, no managed view, dropped on empty space), feedback_node is never cleaned up.

3. Missing cleanup in MOUSE_DRAGGED invalid window path

When the window becomes invalid mid-drag (early return), feedback_node is not cleaned up.

Fix

Proposed patch on my fork: https://github.com/rni34/yabai/tree/fix/feedback-cleanup-on-window-destroy

• Move feedback cleanup BEFORE space_manager_untile_window / view_remove_window_node in both WINDOW_DESTROYED and APPLICATION_TERMINATED
• Add feedback cleanup at the err: label in MOUSE_UP
• Add feedback cleanup in MOUSE_DRAGGED when the window becomes invalid

All cleanup is idempotent — if feedback_node is already NULL, the check is a no-op.

Tested on

• macOS Tahoe (26.x), Apple Silicon
• yabai HEAD-996e26d

[rni34]

TLDR:
I fixed this red screen issue