Repository navigation
cmux NEXT: Shift-Cmd-L opens a browser while a Chromium page has focus - #32849
Merged
austinywang merged 3 commits intoNov 3, 2026
Merged
Conversation
…age (#32789) #32789: Shift-Cmd-L did nothing while a Chromium page had the keyboard. It is one of the rich-text editing chords (Google Docs Left Align), so the router offered it to the page and held New Browser Tab for Chromium's unhandled-key report, which never ran it. Opening a tab is a window key, like Chrome's reserved Cmd-T: the openBrowser actions (KeyRouter.opensTabActions) now run before the page whatever chord they are typed with. Other editing chords (Cmd-B, Cmd-I, Shift-Cmd-E ...) still go to the page first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
austinywang
temporarily deployed
to
ci-routing-agent
November 3, 2026 02:12 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
Contributor
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Shipped in:
|
Contributor
Author
|
Correctness review by a review subagent at 122b75d; re-checked by me at the head, 0046b03. Findings:
Evidence at the head, 0046b03:
|
austinywang
added
the
ready-to-land
Contributor
|
Review (independent-subagent): SHIP at 0046b03 Correctness-first review of the whole diff at this head (BrowserChordTable.swift, KeyRouter+PageFirstKeys.swift, PageFirstKeysTests.swift), against REVIEW.md, REVIEW-STANDARD.md and the CLAUDE.md key-routing rules. Note: the PR was already merged as 447abaf when this review ran; this receipt is after the fact. Checked:
Non-blocking: the base observation used synthetic keys to an inactive window, which the PR says do not reach the renderer. So it does not prove that Chromium's unhandled-key report is broken for the other held chords (Cmd-B Toggle Sidebar). The fix does not depend on that path. A real-key dogfood check of Cmd-B on a plain Chromium page would close that question. |
lawrencecchen
added a commit
that referenced
this pull request
Nov 3, 2026
…E while a plain Chromium page has the keyboard For reopen-f4's unhandled-key path (#32849, lead question). key_state records the front app, debug.focus per window (is_key, resolved, sidebar_hidden) and debug.action_budget recent rows to probe-NAME.json; sidebar_changed checks a toggle against a named key_state. Control: a real Cmd-B in the terminal must toggle the sidebar (it is put back). TEST A (Cmd-B) and TEST B (Shift-Cmd-E) on a plain local page with no key handlers are recorded values.
lawrencecchen
added a commit
that referenced
this pull request
Nov 4, 2026
…sions, dialogs, page-first chords), Rust only (#34052) * docs(focus-core): the agent cursor visibility rules are called through the typed C ABI The module comment still said the app asks over the JSON operation. Since #33313 the Swift resolver calls cmux_agent_cursor_visibility; the JSON operation stays and its FFI test replays the vectors. * test(input-router): the router's scenarios and model-based fuzz, red on today's two key rules (R-INPUT S1a) The one input router (handoff/rewrites/R-INPUT/DESIGN.md, stage S1a) in cmux-focus-core::input, with its tests: a scenario for each key defect class R-INPUT ends (P0 1193, REOPEN-F4/F5, #32633, close-then-type, INVERSE-KEY, a click before the first paint, the cross-window key, keys for Home after a new terminal), and a seeded model-based fuzz against a plain reference model, with seven mutants it must catch. This commit is the red: its router keeps TODAY's two rules of the app's key paths, so the tests fail here: - AppKit's dispatch decides where a key that runs no binding goes (the first responder of the key window), as the key window's first responder does now; - a held key runs again through the router when it leaves its hold, and goes where the focus is then (the CreationInputCoordinator / NewTabInputCoordinator replay through NSApplication.sendEvent). The next commit removes both: a key's sink is decided in the key's own call from the window's focus, and a waiting key leaves its lane only to that sink. The topology's Tab gets the host terminal id (`terminal`), so a creation's stand-in tab and the daemon's tab are one terminal sink. The C topology carries none yet (the FFI decode sets None; the app sends it from S3). Run: cmux-ci run --class isolated --script scripts/ci/cmux-tui-rust-check.sh --os linux --arg test --arg key_router:: --ref <this sha> * fix(input-router): a key's sink is fixed in the key's own call; a waiting key leaves its lane only to that sink (R-INPUT S1a) Removes today's two rules from the router (see the red commit): - the sink of a key that runs no binding comes from the window's focus at key time: the tab the focus is on its way to (a creation's), else the focused target. AppKit's dispatch only chooses HOW the key reaches that sink (its responder when it reaches it, else the sink's own path), never which sink; - a key that waits stays in its sink's lane until that sink can take it, and leaves only to it, in typing order; when the sink ends the key is dropped with the reason. No re-aim, no replay through the router, no timer. Rust only, no caller yet: the app links it from stage S3 (shadow), and the behavior stages flip one runtime switch each (DESIGN.md section 5). * fix(input-router): the router's send-or-queue step is route_to, not to_sink (clippy wrong_self_convention) A to_* method that takes &mut self breaks clippy's naming rule (green step 759965538c90: fmt and the 25 tests passed, clippy -D warnings failed on this name only). A pure rename; no behavior change. * test(input-router): key sessions, dialogs, page-first chords and the Escape rule, red on today's rules (R-INPUT S1b) Stage S1b of the one input router (handoff/rewrites/R-INPUT/DESIGN.md sections 4.4, 4.7 and 4.8), Rust only, no caller yet: - key sessions (link hints the person started, window hints, the shortcut recorder): at most one runs (I5), and a key it takes reaches no sink (I4); - blocking dialogs (a window's or one tab's): a key typed under a dialog is the dialog's, a key typed before it waits for the answer with its own target; - page-first chords: a chord a page may own goes to the page first, and its action runs once, by the key's own id, only when the page leaves it unhandled; - Escape in a field the person moved into from content gives the keyboard back to that content (#33049). The tests: 20 scenarios (#32537 review rounds, #31849, #32291/#32409, #32849, #33049, with their STATUS items), the reference model and the fuzz extended with sessions, dialogs and page reports, and four more mutants the fuzz must catch (a hint letter to the page, two sessions, an action run twice, a key under a dialog to its target). This commit is the red: the router keeps TODAY's rules (no key session in the router, a dialog gets keys only through AppKit, a bound chord runs at once, Escape stays in the field), so the tests fail here. The next commit adds the rules. * fix(input-router): sessions take their keys, dialogs block their targets, page-first chords wait for the page's report, Escape returns from a field (R-INPUT S1b) Adds the four rules to the router's one decision per key (see the red commit): - a running key session takes its window's hint keys (letters, Backspace, Escape; the recorder: every key) in the key's own call; any other key, a key of another window, a focus move off its target, its window closing or a newer session ends it, and that key then routes as usual. At most one runs; link hints start only on the page the window's keys go to; - a dialog that blocks a key's target takes the key (a bound chord still runs), and a target a dialog blocks takes no key: keys typed before the dialog wait for the answer and go on in order, or are dropped when the answer closes their tab; - a chord a page may own (Find, a page-editing chord, a content action) goes to the focused page first when the page takes keys now; its action runs once, aimed at the key's tab, when the page reports that key unhandled. A report of a newer key forgets the older offers (a page reports in key order); - a bare Escape in a sidebar or text field the person moved into from content gives the keyboard back to that pane, unless the field uses Escape itself. Rust only, no caller yet: the app links it from stage S3 (shadow), and S6/S7 flip input.router.pageKeys and input.router.overlays (DESIGN.md section 5). * test(input-router): sink lifetimes, creation replies, actions that wait, the key's own target for its binding (R-INPUT S1 review), red Scenarios for the findings of the first independent review of PR #34052 and for the fuzz failure of the S1b green step (fleet step 1803a1b30c2e, seed 39, I7: a key reached Host("T2") after the ledger saw T2 end): - a terminal that ended takes no key while its tab still shows, and takes keys again only when a window shows it after none did (seed 39); - Reopen Closed brings a tab back under its old id: the new page takes keys after its own first paint; a creation that names an ended tab again makes it a new sink (finding 1); - a creation that fails after its stand-in showed still ends its terminal: waiting and later keys are dropped with the reason (finding 2); - a Paste before a page's first paint waits for it and keeps its place; a Paste under a dialog runs at once (finding 3); - a Ghostty keybind typed for a new tab runs its action (finding 8); - the 1193 scenario checks the tab each Cmd-D runs on (finding 9); - a key-down that reached nothing has no repeat or release anywhere (finding 10); - an address bar expected by surface takes the keys typed for it (finding 11); - seed 39's shrunk case: a key for the open palette waits for it and always ends (delivered, or dropped when the palette closes). This commit is the red: the router is unchanged, so these tests fail here (the palette and 1193 checks pass: they pin behavior that is right today). * fix(input-router): an ended sink takes keys only as a new sink, creations stay known until their reply, input actions wait like keys, the binding rules read the key's own target (R-INPUT S1 review) Fixes the findings of the first independent review of PR #34052 and the fuzz failure of the S1b green step (fleet step 1803a1b30c2e, seed 39): - Sink lifetimes (finding 1, seed 39): a tab's sink that ended takes no key while its tab still shows, and takes keys again only as a new sink: a window shows it again after none did (Reopen Closed reuses the tab id), or a creation names it again. An ended sink that no window shows and no held key names is forgotten. The router says so with the new SinkEnded and SinkNew effects, and the ledger follows them, so its I7 check holds across a reused id. A window's field, overlay or dialog never ends that way. - Creation replies (finding 2): a creation stays known until its reply (new event Created, or CreationFailed), so a failure after the stand-in showed still ends its terminal. Creation carries the tab's kind. - Input actions (finding 3): an action that edits an input (Paste) waits in that input's lane while the input cannot take input, like a key, and runs when a key could go; under a dialog it edits the dialog's input at once. - Lane limit (finding 7, R9 R-L1): LaneLimit::for_memory derives the bound from physical memory (1/4096 of it, at 1 KiB a waiting key: 4096 keys on 16 GiB); the platform reads hw.memsize at start. - Binding rules (finding 8): the tier and Ghostty rules read the key's own target (the tab the focus is on its way to), the same state as its sink; a page gets a chord first only when the key is aimed at that focused page. - A press that reached nothing (finding 10): no target, dropped, or its sink became a new one: its repeats and release are consumed. - Expected targets (finding 11): a chrome target only on a browser tab, as the focus reducer keeps it; a creation known by its surface keeps its tab. - The ledger keeps only what can still change (finding 6), and names its two protocol checks OwnCall and IdOrder. - Tests: the fuzz runs 20,000 cases of 200 events on every core, with a lane limit of 8, new actions (creation replies after the show, Reopen Closed with the same id, an end while the tab shows, chrome targets, surface keys), ids that never repeat by chance, and a finale the checker adds itself (the shrinker can no longer cut it off, which made seed 39's shrunk case look like a waiting key). It compares the action and tab of every run (finding 9). Two more mutants (I7: a key to an ended sink; I8: an unbounded lane), and the mutant test checks that the real router passes each case first. A counting allocator checks 0 allocations per key, release and bound chord. The router splits into lane, lifetime and binding modules. * fix(input-router): the fuzz finale's window list uses a match guard (clippy collapsible_match) Green step 05d9b051358a at 5ddd5d8 passed fmt and all 56 key_router:: tests (the 20,000-case fuzz, the 0-allocation test, the 13 mutants) and failed clippy -D warnings on one collapsible_match in the test target (fuzz.rs:814). No behavior change. * test(input-router): exits that stay ended, creations done before their tab shows, offers per page with a visible end, bare keys under a dialog (R-INPUT S1 second review), red Scenarios for the findings of the second independent review of PR #34052 (receipt #34052 (comment)): - an exited terminal takes no key after a workspace switch, a tab move or a window reopen, until a restart names it again; an exited terminal whose tab closes is a new tab when reopened (finding 2); - a creation done before its tab shows keeps the keys typed for its terminal (finding 1); - a page that does not report unhandled keys (WebKit) gets no offer: its chords run at once (finding 3); - the offers waiting for one page are bounded by the lane limit and the oldest past the bound closes visibly; a page that closes closes its offers; a handled report closes the offer and the page's older ones (finding 4, R9 R-L1/R-L5); - one page's report keeps the offers of another page (finding 5); - a bare bound key under a dialog goes to the dialog (finding 6); - a Paste for an exited terminal is dropped like a key (finding 7); - copy mode is the focused terminal's, not a new terminal's; the release of an offered key reaches its page; a Paste under a dialog names no tab (nits). The API gets what the tests name: GoneReason::Exited, the PageHandled event, the OfferClosed effect with OfferEnd, and KeyRecord.page_reports_unhandled. The ledger checks I4 on key-downs (a key-down typed while a session runs is the session's unless the session ended first in the call) and accepts an offer's close. The reference model and the fuzz state the new rules; the generator adds replies before the show, exits, restarts, workspace switches and handled reports. This commit is the red: the router is unchanged, so these tests fail here. * fix(input-router): an exited terminal stays ended until a restart, a done creation keeps its keys until its tab shows, offers go only to pages that report and end once per page (R-INPUT S1 second review) Fixes the findings of the second independent review of PR #34052: - Exits (finding 2): GoneReason::Exited is an end whose tab stays (a terminal's process ended). The sink stays ended wherever its tab shows (a workspace switch, a tab move, a window reopen) until a creation names it again (a restart) or its tab closes. Only a closed or failed sink becomes new when a window shows it again after none did (Reopen Closed). - Creations (finding 1): a done creation is kept until a window shows its tab, so a reply that comes before the store's delta never sends the keys for the new terminal to the old target. One reply a creation: a failure after "done" changes nothing. - Offers (findings 3-5, R9 R-L1/R-L5): only a page that reports the keys it leaves unhandled (KeyRecord.page_reports_unhandled, the app's KeyFacts.pageReportsUnhandledKeys) gets a chord first, so a WebKit page's chords run at once as today. Each offer ends exactly once: its action runs, or OfferClosed says why not (Handled, PageGone, Overflow). A page's answer (PageUnhandled, or the new PageHandled) closes only that page's older offers. The offers waiting for one page are bounded by the lane limit (from physical memory), and the oldest past it closes visibly. - A bare key under a blocking dialog is the dialog's, bound or not; a Command or Control chord still runs (finding 6). - An input action for an ended input is dropped with its reason, like a key (finding 7); under a dialog it names no tab. - Copy mode is the focused terminal's, never a new terminal's; the release of a key-down a page got first goes to that page after a repeat that ran; readiness after SinkNew is documented (nits). * test(input-router): a newer key's report closes the older offers as handled, visibly (R-INPUT S1 second review) Green step 2dfb26f0dc2c at f7edc24: fmt and clippy -D warnings on all targets passed, and 67 of 68 key_router:: tests passed (the 20,000-case fuzz, the 13 mutants, the 0-allocation test and the four regression tests of the second review). The one failure was this S1b scenario: it asserted the old rule, where a newer key's report made the older offers vanish with no sign. DESIGN.md 4.7 (v1.3) and R9 R-L5 say every offer ends exactly once, visibly: the older offer closes with OfferClosed { Handled }, and its action never runs. The router is right; the test now asserts that rule. * test(input-router): a failed restart keeps an exited terminal ended; a blocking dialog takes bare keys before a session (R-INPUT S1 third review), red The third independent review of PR #34052 (at 679b1d1, receipt #34052 (comment)): - major: "Restart Shell Here" on an exited terminal's tab is a creation of the same terminal. When it fails, the dead tab stays, but the router records the end as CreationFailed, which follows the closed-tab rule: after a workspace switch, a tab move or a window reopen the terminal is new again, and keys go to a shell that does not run. Scenario a_failed_restart_of_an_exited_terminal_keeps_it_ended_wherever_it_shows. The fuzz: a restart's failure keeps its tab (World::restart marks its reply), so later seeds reach this path. - minor: a running key session took bare keys typed under a blocking dialog; today the dialog gets them first. Scenario a_blocking_dialog_takes_bare_keys_before_a_running_session. This commit is the red: the router is unchanged. * fix(input-router): a failed restart leaves an exited terminal exited; a blocking dialog takes bare keys before a key session (R-INPUT S1 third review) Fixes the two findings of the third independent review of PR #34052: - A creation remembers that it restarts an exited sink. When it fails, the dead tab stays, so the sink ends as Exited again, not CreationFailed: it stays ended wherever its tab shows (a workspace switch, a tab move, a window reopen) until another restart works. - A blocking dialog over the key's target takes a key with no Command or Control before any key session and any binding (dialog_first, DESIGN.md 4.4 step 3, v1.4): today's order, and Chrome's (a page's alert blocks its hint script). The session keeps running and takes its keys again after the answer. A key of another window still ends a running session first. The ledger's I4 check accepts a dialog's key while a session runs. The reference model states both rules. DESIGN.md section 8 lists the behavior changes of S1. * test(input-router): the ledger requires the offers of a page to end in key order (R-INPUT S1), red At dce7c8c the ledger accepted an offer's OfferClosed but did not require it: an older offer that vanished with no end (the expectation that 679b1d1 replaced) passed the ledger. DESIGN.md 4.7 says a page answers its keys in key order and every offer ends exactly once, so the offers to one page must end in key order (I3). This test feeds the ledger both streams directly, with no router and no model: the silent one must break I3 at the newer key's run, and the router's order (the older offer closed as handled, then the newer key's run) must pass. This commit is the red: the ledger is unchanged. * fix(input-router): the ledger requires the offers of a page to end in key order (R-INPUT S1) The ledger keeps each open offer's page, and an offer's end (its action's run, or its OfferClosed) while an older offer to the same page is still open breaks I3. A page answers its keys in key order (DESIGN.md 4.7), so an older offer that vanished with no end can no longer pass: the check that the PR body claimed now exists. Every end the router emits is in that order (an answer closes the page's older offers before it runs or closes its own key; a page's end and an overflow close the oldest first). * fix(input-router): the ledger order test passes its one-effect slice with slice::from_ref (clippy cloned_ref_to_slice_refs) Green step fd523cb817e1 at 75ed18a passed fmt and 71 of 71 key_router:: tests, and failed clippy -D warnings on this one line of the new ledger test (sessions.rs:634). No behavior change.
This branch was previously deployed
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.
Fixes #32789
Summary
Shift-Cmd-L (New Browser Tab) did nothing while a Chromium page had the keyboard. Shift-Cmd-L is also one of the rich-text editing chords (
BrowserChordTable.pageEditingChords; it's Left Align in Google Docs). The router therefore offered the key to the page first and held New Browser Tab until Chromium reported the key unhandled, and that report never ran it.Opening a tab is a window key, like Chrome's reserved Cmd-T, which a page never keeps. The
openBrowseractions (KeyRouter.opensBrowserActions) now run before the page on any chord. The other editing chords (Cmd-B, Cmd-I, Shift-Cmd-E, ...) still go to the page first. The code editor keeps its own Cmd-Shift-L (Select All Occurrences) throughyieldsToCodeEditor.Trade-off: in Google Docs, Shift-Cmd-L opens a browser instead of left-aligning, as the issue asks ("open a new browser from any focused pane").
Testing
Regression:
PageFirstKeysTests/openBrowserRunsBeforeAChromiumPage(router decision for Shift-Cmd-L in a Chromium page).cmux-ci run --class light --script scripts/ci/run-swift-testing-suites.sh --arg=Packages/macOS/CmuxNext --env CMUX_SWIFT_TEST_SUITES=PageFirstKeysTests, step 2ec349c92aee0c5c57398928:openBrowserRunsBeforeAChromiumPage() recorded an issue, 1 of 9 failed.CMUX_SWIFT_TEST_SUITES=PageFirstKeysTests,CodeEditorKeysTests: step d871d0ae76f74d9e5ac13c35 at 0046b03: PageFirstKeysTests 9/9 and CodeEditorKeysTests 5/5 pass.Observed / Not run
32789-base-cmd-shift-l) throughdebug.key: Shift-Cmd-L into a Chromium page window tracedofferToPage(openBrowser), and no New Browser Tab ran afterward.Review
A correctness review subagent found no bugs. Its two comment nits were fixed in 0046b03: the set is renamed to
opensBrowserActions, and theoffersToPagedoc names the exception.Changelog
risk: normal (key routing for one action).
🤖 Generated with Claude Code