Tab-switch shortcuts - #483
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1ef4c7d785
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const key = e.key.toLowerCase(); | ||
| // Tab navigation first (both shift variants): ⌘1-8 = nth tab, | ||
| // ⌘9 = last tab, Ctrl+Tab / Ctrl+Shift+Tab cycle (Chrome). | ||
| if (mod && !e.altKey && key === 'tab') { |
There was a problem hiding this comment.
When the user is actually interacting with a loaded page, focus is in the native tab WebContentsView rather than this React window, so this renderer-only keydown handler will not see Ctrl+Tab and the adjacent number-key shortcuts; I checked src/main/browser and there is no before-input-event/equivalent forwarding for these accelerators. As a result the new tab-switching shortcuts only work while the chrome/start page has focus, missing the normal browsing case the shortcut is meant to cover.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed — each tab view now mirrors the accelerators via before-input-event, so ⌘1-9 and Ctrl(+Shift)+Tab work while a page has focus; renderer handler stays for chrome focus (bb62636).
Chrome muscle memory: ⌘1-8 activates the nth tab, ⌘9 the last, and Ctrl(+Shift)+Tab cycles with wraparound. Renderer-only (state.tabs + activate); handled before the other mod-combos so ⌘1-9 never collides with future shortcuts.
Codex on #483: the renderer keydown only sees ⌘1-9 / Ctrl+Tab when the browser chrome has focus — interacting with a loaded page puts focus in the native WebContentsView and the shortcuts went dead. Each tab view now mirrors the same accelerators via before-input-event (⌘1-8 nth, ⌘9 last, Ctrl(+Shift)+Tab cycles), with a test driving the event through a fake view.
5c5919d to
4430c09
Compare
1 participant
What
Chrome's tab-switching muscle memory, in the browser route:
Single-tab windows make the shortcuts quiet no-ops, and they don't interfere with the existing ⌘T / ⌘W / ⌘F / ⌘⇧T bindings.
Stacked on
pr/reopen-closed-tab.For QA