fix(preview): exclude the panel from tab order while closed (real Shift+Tab root cause) - #10
Merged
Merged
Conversation
Root cause of the "Shift+Tab opens the preview" report on both Windows and macOS: xterm.js's evaluateKeyboardEvent deliberately leaves Shift+Tab uncancelled (cancel: false only on that branch — plain Tab, Enter, and Escape all set it true) so app-level Shift+Tab chords, like Claude Code's own plan-mode toggle, still reach the pty. That also means the browser's native reverse-tab-order focus navigation runs uninterrupted. The file-preview panel stays in the DOM (translated off-screen) rather than display:none so its slide-in CSS transition can animate, which left its Copy/Edit/Close buttons real, always-focusable elements sitting right before the terminal panes in DOM order — exactly where Shift+Tab from the terminal would land. Confirmed live: before this fix, real Shift+Tab moved focus onto #file-preview-close; after, it skips straight to the next earlier focusable element (the window's own close button). Buttons now start tabindex="-1" and only become tab-reachable while the panel is actually open, so Shift+Tab from the terminal can never land on them (and can't scroll the off-screen panel into view either). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GHgSVKPsaWRfuJMo1rc2AN
1 task
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
Found and fixed the actual root cause of "Shift+Tab opens the file preview panel" reported on both Windows and macOS (the previous PR #8 hardened the click/Escape paths but never addressed the real trigger).
xterm.js's
evaluateKeyboardEventdeliberately leaves Shift+Tab uncancelled (cancel: false) — unlike plain Tab/Enter/Escape which all setcancel: true— so app-level Shift+Tab chords (e.g. Claude Code's own plan-mode toggle) still reach the pty. That also means the browser's native reverse-tab-order focus navigation isn't suppressed.The file-preview panel stays in the DOM (translated off-screen via CSS, not
display:none, so its slide-in transition can animate), which left its Copy/Edit/Close buttons as real, always-focusable elements sitting right before the terminal panes in DOM order — exactly where Shift+Tab from the terminal lands. The buttons now starttabindex="-1"and only become tab-reachable while the panel is actually open.Verification
Confirmed live against an isolated test build (separate Tauri identifier + CDP/Playwright), not just read from the code:
#file-preview-close.Test plan
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
https://claude.ai/code/session_01GHgSVKPsaWRfuJMo1rc2AN