fix(wm): refocus selection on destroy when foreground goes null#1727
Open
MattKotsenas wants to merge 1 commit into
Open
fix(wm): refocus selection on destroy when foreground goes null#1727MattKotsenas wants to merge 1 commit into
MattKotsenas wants to merge 1 commit into
Conversation
Reactive events pass trigger_focus=false so komorebi follows the OS foreground and reconciles via the FocusChange handler once Windows promotes a successor window. When the destroyed window was the foreground and Windows promotes nothing, the foreground becomes null, no FocusChange arrives, and komorebi's selection never regains OS focus, leaving every border unfocused until the user refocuses by hand. Add a narrow fallback in the Destroy/Unmanage handler: when the OS foreground is null after removal, focus the current selection. Any non-null foreground is left to FocusChange, so the OS is not fought and the should_skip_focus_change desync cannot occur.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Closing the focused (foreground) tiled window sometimes does not move focus to a surviving neighbor. komorebi removes the window and re-tiles, but no managed window regains focus. Borders render unfocused on every window and keystrokes do nothing until the user refocuses by hand.
Root cause
The removal handlers (
Destroy/Unmanage,Minimize,Hide) callupdate_focused_workspace(false, false), which re-tiles but leaves focus to the OS. komorebi reconciles its selection in theFocusChangehandler once Windows promotes a successor. From looking atgit blame, this appears intended to prevent focus fights.When the focused window is destroyed, Windows does not always promote a successor. When it promotes nothing, the foreground becomes null, no
FocusChangearrives, and the selection never regains OS focus.Fix
Keep the reactive no-force-focus default and add a narrow fallback in the
Destroy/Unmanagehandler: when the OS foreground is null after removal, follow and trigger focus soupdate_focused_workspacerestores komorebi's own selection (maximized/monocle/tiling). A non-null foreground is still left toFocusChange, so the OS is not fought and theshould_skip_focus_changedesync should not occur.Added a small predicate (
should_refocus_after_destroy) with unit tests, mirroring the existingshould_skip_focus_change.Notes
I haven't been able to reproduce the behavior in the
MinimizeorHidepaths, so I haven't touched them. It's probably safe to extend the fix there too, so happy to include those paths as well if desired.