fix(app): restore first responder after native tab close#26
Merged
Conversation
Closing a native macOS tab left the surviving tab unable to receive keyboard input: AppKit's tab teardown makes the survivor key but moves first responder off winit's content NSView, so keyDown: never reaches WinitView and WindowEvent::KeyboardInput goes silent. The previous deferred-RestoreFocus fix only called focus_window() (makeKeyAndOrderFront:), which does not reassign first responder when the target window is already key — a no-op for this failure mode. Add macos_window::focus_content_view, which resolves the AppKit NSView from the raw window handle and sends makeFirstResponder: to its window. Call it (plus a set_ime_allowed off/on toggle to discard stale marked text) from both the RestoreFocus handler and the Focused(true) path, so recovery does not depend on where the deferred event lands relative to AppKit's teardown. Non-macOS paths unchanged.
simota
added a commit
that referenced
this pull request
Jul 17, 2026
…estore (#27) Two regressions from the native-tab-close focus fix (#26): Search opening uninvited: closing a tab with cmd+w destroys the view before the Cmd-release flagsChanged reaches winit, so the app's stored modifiers stay stuck holding SUPER and the next plain keypress on the surviving tab resolves as a chord (plain f -> cmd+f -> Search/Find). Reset stored modifiers on Focused(false) and in the RestoreFocus handler; winit re-sends ModifiersChanged on the next real modifier press, so nothing is lost. Regression test locks the resolution semantics the reset relies on. Intermittent crash on the same gesture: the belt-and-suspenders block added to Focused(true) ran makeFirstResponder: plus an IME off/on toggle synchronously inside the winit handler on every focus gain, including mid-teardown ones — a re-entrancy/teardown race. Remove it; focus restore after tab close lives solely on the deferred RestoreFocus path, which keeps the first-responder + IME re-arm.
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.
Summary
新規タブを追加して閉じた後、生存タブでキーボード入力が効かなくなる不具合(再発)の修正。
keyDown:が届かずWindowEvent::KeyboardInputが沈黙する。RestoreFocus修正はfocus_window()(makeKeyAndOrderFront:)のみで、対象が既にkeyの場合firstResponderを再割当てしない=この故障モードにはno-opだった。macos_window::focus_content_view()を追加しmakeFirstResponder:を直接送出。RestoreFocusハンドラとFocused(true)の両経路で firstResponder復元 +set_ime_allowedoff/on(stale marked textの破棄)を実施。非macOS経路は不変。Test plan
cargo build --workspace/cargo clippy --workspaceクリーンcargo test -p noa-app: 966 passedexitで閉じる経路も同様。NOA_IME_TRACE=1で打鍵時に[ime-trace] Key:が出ることを確認。