fix(vscode): prevent questions from stealing typing focus - #13531
Merged
Conversation
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (6 files)
Reviewed by grok-4.6 · Input: 127.4K · Output: 11.8K · Cached: 391.4K Review guidance: REVIEW.md from base branch |
marius-kilocode
enabled auto-merge
August 28, 2026 07:45
WebReflection
approved these changes
Aug 28, 2026
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
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.
What Problem This Solves
An open question can move focus from the chat composer to its first answer while a draft is being typed. Further text then misses the composer, and a space can accidentally select that answer.
Why This Change Was Made
The question dock and Agent Manager both schedule question autofocus. The dock only checked whether the webview had focus, while Agent Manager's editable-field guard excluded the chat composer. A repeated question delivery could therefore take focus even though the composer was active.
Check the active text control when each deferred focus callback runs. Keep explicit focus commands and question keyboard navigation unchanged. No question recovery, network, or timing changes are needed.
User Impact
New questions and repeated question deliveries leave active text fields in control. Users can continue writing a draft or custom answer without losing focus. Arrow-key selection and navigation between question pages still work.
Evidence
The self-test used deterministic session and question messages in the real webviews, with no credentials or model calls. It verifies UI handling rather than live SSE recovery. Synthetic session IDs produced expected backend
Session not founddiagnostics. The isolated VS Code instance was cleaned up afterward.Manual check: leave a question open and type in the bottom composer. Confirm that focus remains there, then select an answer and verify Arrow-key navigation.
Before: the first answer takes focus and the draft is incomplete.
After: the composer keeps focus and all text reaches the draft.