fix(terminal): own Shift+Tab explicitly to stop chrome-focus shading - #11
Merged
Conversation
…rough The tabindex fix stopped Shift+Tab from landing on the (now unreachable) preview panel buttons, but the underlying cause was still live: xterm.js leaves Shift+Tab uncancelled on purpose, so the browser's native reverse- tab-order focus navigation still ran on every Shift+Tab keystroke — it just landed on the next focusable chrome button instead (confirmed live: the window's own close button lit up with a focus ring). Since the app never wants Shift+Tab to move focus around its own chrome while a terminal has it, handle the chord explicitly: preventDefault it and send the same CSI Z sequence xterm would have sent ourselves. The hotkey (e.g. Claude Code's plan-mode toggle) still reaches the pty with zero focus side-effect — confirmed live, activeElement stays on the terminal's own textarea through the keystroke. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GHgSVKPsaWRfuJMo1rc2AN
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
Follow-up to #10, which fixed Shift+Tab from opening the file preview panel (removed its buttons from the tab order). That fix left the underlying cause still live: xterm.js leaves Shift+Tab uncancelled on purpose (so app-level chords like Claude Code's plan-mode toggle still reach the pty), so the browser's native reverse-tab-order focus navigation still ran on every Shift+Tab — it just landed on the next focusable chrome button instead of the preview panel (confirmed live: the window's own close button lit up with a focus ring).
Since the app never wants Shift+Tab to move focus around its own chrome while a terminal has it, this handles the chord explicitly in
attachCustomKeyEventHandler:preventDefault()+ send the sameCSI Zsequence xterm would have sent, so the hotkey still reaches the pty with zero focus side-effect.Verification
Confirmed live via an isolated test build (separate Tauri identifier, CDP + Playwright): before,
document.activeElementmoved to a chrome button after a real Shift+Tab keystroke; after, it stays on the terminal's own textarea, no console errors.Test plan
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
https://claude.ai/code/session_01GHgSVKPsaWRfuJMo1rc2AN