fix(tui_v3): recover Windows VT input mode after focus loss (closes #633)#652
Open
Kailigithub wants to merge 1 commit into
Open
fix(tui_v3): recover Windows VT input mode after focus loss (closes #633)#652Kailigithub wants to merge 1 commit into
Kailigithub wants to merge 1 commit into
Conversation
…sdefine#633) When a Windows console host (Windows Terminal, conhost, or legacy cmd) loses focus or sees another console process attach/detach, it sometimes clears the ENABLE_VIRTUAL_TERMINAL_INPUT flag on the standard input handle. Without that flag, prompt_toolkit stops receiving arrow keys, function keys, and other ESC-prefixed sequences, and the input pane appears frozen until the user restarts the TUI. Two changes: 1. _enable_windows_vt_mode() now also sets ENABLE_VIRTUAL_TERMINAL_INPUT (0x0200) on STD_INPUT_HANDLE in addition to the existing VT-output flag on STD_OUTPUT/STD_ERROR. Only flips bits that are not already set, so it is idempotent on every call. 2. The async maintenance loop on Windows now re-invokes _enable_windows_vt_mode() + _enter_utf8_charset() once per second. Because the existing loop already runs every 30ms, the new behavior is purely additive — no extra thread, no extra tick. When the user alt-tabs away and back, input is restored within ~1s instead of requiring a full TUI restart. Non-Windows callers see no change: both branches are gated on the _IS_WINDOWS module flag and the VT helpers no-op on other platforms.
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
Fixes #633 — TUI v3 input pane becomes unresponsive after switching away from the terminal window and back, on Windows.
Root cause
Some Windows console hosts (Windows Terminal, conhost, legacy
cmd.exe) reset the standard input handle'sENABLE_VIRTUAL_TERMINAL_INPUT(0x0200) flag when the window loses focus or when another console process attaches/detaches. Without that flag, prompt_toolkit stops receiving arrow keys, function keys, and other ESC-prefixed sequences; the input pane therefore looks frozen until the user restarts the TUI.Changes
frontends/tui_v3.py— two additive changes, fully backward-compatible on non-Windows:_enable_windows_vt_mode()now also ORs inENABLE_VIRTUAL_TERMINAL_INPUTonSTD_INPUT_HANDLEalongside the existingVT_OUTPUTflag onSTD_OUTPUT_HANDLE/STD_ERROR_HANDLE. Only flips bits that are not already set, so the call is idempotent.The async maintenance loop, on Windows, now re-invokes
_enable_windows_vt_mode()+_enter_utf8_charset()once per second. The loop already ticks every 30ms, so this is purely additive — no new thread. After alt-tabbing back to the terminal, input is restored within ~1s instead of requiring a full TUI restart.Test plan
python frontends/tui_v3.py, type some text, alt-tab away for >2s, alt-tab back, confirm arrow keys + Enter still work.cmd.execonhost: same scenario.if _IS_WINDOWSbranch never fires (no behavior change).python -m py_compile frontends/tui_v3.py(passes) andruff check(no new findings introduced).Closes #633