Skip to content

fix(browser): unstick Ctrl+Tab switcher when opened from a focused browser guest - #9965

Closed
fazalk21 wants to merge 1 commit into
stablyai:mainfrom
fazalk21:fix/switch-tab
Closed

fazalk21 wants to merge 1 commit into
stablyai:mainfrom
fazalk21:fix/switch-tab

Conversation

@fazalk21

Copy link
Copy Markdown

Summary

Fixes #9937.

Ctrl+Tab from a focused in-app browser opened the MRU Switch Tab overlay but never committed or closed it, because guest before-input-event called preventDefault() on the Tab keydown and Electron then suppressed the Control keyup that should emit ui:ctrlTabKeyUp.

Stop preventDefault-ing that keydown in guest shortcut forwarding (same approach as the main-window path in createMainWindow.ts), so the existing IPC commit path can fire on modifier release.

What changed

Before: Guest Ctrl+Tab keydown was preventDefault()-ed → guest keyups were dropped → overlay stayed stuck until focus left the browser tab.

After: Guest Ctrl+Tab keydown is forwarded without preventDefault() → Control keyup reaches the guest handler → ui:ctrlTabKeyUp commits/closes the overlay normally.

Screenshots

No visual change (behavior-only fix for an existing overlay).

Testing

  • pnpm lint
  • pnpm typecheck
  • pnpm test (targeted: browser-guest-ui.test.ts, browser-manager.test.ts Ctrl+Tab cases)
  • pnpm build
  • Updated unit expectations so guest Ctrl+Tab keydown must not call preventDefault

AI Review Report

Root cause matches the documented main-window comment: preventing the held-chord keydown suppresses the modifier keyup and strands the overlay. Alternative approach in #9954 keeps preventDefault and blurs the webview so renderer DOM handlers own the rest of the gesture; this PR prefers the smaller change that removes the suppression trigger and stays consistent with createMainWindow.

Cross-platform: no new shortcuts/labels/paths; chord matching stays behind matchesRecentTabSwitcherChord / keybinding registry. Electron keyup-suppression after preventDefault is platform-independent (reported on Linux, same guest path on macOS/Windows). SSH unaffected (UI keyboard routing only).

Security Audit

No new IPC channels or guest-supplied data paths. Change only removes preventDefault on an already-forwarded app chord; existing main→renderer ui:ctrlTabKeyDown / ui:ctrlTabKeyUp trust boundary is unchanged. Pages may observe Ctrl+Tab (previously swallowed); most pages ignore it.

Notes

Related alternative: #9954 (blur webview + focus restore + E2E). This PR is the minimal main-window-aligned fix for the same root cause.

Made with Cursor

Electron suppresses guest keyups after a prevented Ctrl+Tab keydown, so the
MRU switcher never received ui:ctrlTabKeyUp and stayed stuck open (#9937).
Match the main-window path: forward the chord without preventDefault.

Co-authored-by: Cursor <cursoragent@cursor.com>
@fazalk21

Copy link
Copy Markdown
Author

Closing — will re-open from Fazalkadivar21.

@fazalk21 fazalk21 closed this Jul 22, 2026
@fazalk21
fazalk21 deleted the fix/switch-tab branch July 22, 2026 18:13
@coderabbitai

coderabbitai Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b880b219-8779-4b9c-b965-0cae2f190949

📥 Commits

Reviewing files that changed from the base of the PR and between 6ad6241 and 39a35bf.

📒 Files selected for processing (3)
  • src/main/browser/browser-guest-ui.test.ts
  • src/main/browser/browser-guest-ui.ts
  • src/main/browser/browser-manager.test.ts

📝 Walkthrough

Walkthrough

The guest keyboard handler no longer calls preventDefault() for the initial Ctrl+Tab keydown. Comments document Electron’s Control keyup behavior, and browser guest UI and browser manager tests now assert that keydown prevention is not called. Subsequent release and keyup event expectations remain unchanged.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely describes the main fix: unfreezing Ctrl+Tab in a focused browser guest.
Description check ✅ Passed All required sections are present, and the summary, testing, AI review, security, and notes are adequately filled out.
Linked Issues check ✅ Passed The change matches #9937 by removing the guest Ctrl+Tab preventDefault that blocked keyup and kept the overlay stuck.
Out of Scope Changes check ✅ Passed The diff is narrowly scoped to the Ctrl+Tab guest handler and related tests, with no unrelated changes evident.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Ctrl+Tab Switch Tab overlay gets stuck open when focus is on the in-app browser tab

2 participants