fix(app): keys typed after Cmd-N then Ctrl-` reach the new terminal, not the New Tab page (P0)

LA
5d ago
+119-10

Summary

  • Judged smoke of dogfood build v2.2.13-opt (STATUS 3190), round 2 step 16: after Cmd-N, Ctrl- and a typed line, the line's keys went to the New Tab page (a Chromium page window), not the new terminal. Found while porting #29530 to the dogfood line (#30271): its end-result test shows the new terminal's screen empty (sh-3.2$`) and all 10 keys "consumed" by the key router, none held by the creation hold.
  • Cause: Cmd-N opens the window's New Tab hold (NewTabInputCoordinator.beginIncoming), so every key waits for the new page's field. The Ctrl-(or Cmd-D, New Column, New Row, a browser tab) pressed then opens its creation hold, but the New Tab hold runs first inKeyRouter.interceptKeyDown, and nothing ended it (its chord release fires only when it already holds keys). So the keys typed after the Ctrl- waited for the page and went to its field.
  • Fix, one seam for every creation that moves a window's focus: CreationInputCoordinator.begin ends that window's New Tab hold once its own hold is open (NewTabInputCoordinator.creationTookKeys, the same window lookup capture uses). The keys that hold kept run again through the key router in typing order, so they go into the creation's hold first. A script's creation (no view change allowed) opens no hold and ends none. No App line growth.

Testing

  • Red first: CmdNThenCreateKeysTests (9856f7ff2e9): Cmd-N with the daemon stopped, then Ctrl- (and Cmd-D), then "echo held" Return, each key through the app's dispatch (interceptKeyDown, then the window; held keys replay the same way). Pass only when the new terminal's screen shows the line and the shell's answer held`, and no other terminal shows it.
  • Compile: a2dad0a6b74370c26adc2d61 passed (CmuxNext with tests, app, cmux-tui).
  • Test fix 3cfc05ad6001: the test's New Tab page never reports ready, so on the base its page hold handed the keys on at its 4 s bound and the first red (808acd14b268c72028550d5a at 9856f7ff2e9) PASSED by mistake. The test now sets incomingHoldLimit to 120 s, so the page hold keeps its keys while the page opens, as a person's does until their page is ready.
  • Compile at the head 3cfc05ad6001: c0a97fcacad0dfe21b20c2df passed (CmuxNext with tests, app, cmux-tui).
  • Red, CmdNThenCreateKeysTests at 13df94df1c34 (the head with the fix 6bf54ebb4036 reverted; run as role base, display, CMUX_TEST_REQUIRE_GUI=1): 6577bde00daddb56b5f50bb0 FAILED both tests at CmdNThenCreateKeysTests.swift:98: the new terminal's screen is sh-3.2$, and all 10 keys were consumed with "New Tab hold true".
  • Green at the head 3cfc05ad6001: fd2b6cd4fd63beb7cced8a97 PASSED: CmdNThenCreateKeysTests 2/2 (Ctrl-and Cmd-D: the typed line andheld` show in the new terminal, and no other terminal shows the line), CmdNThenNewTerminalTabTests 3/3, gui-session-v1 console line present.
  • Router probe on the feat tip 4976f6e50282 with only the test (branch fix/p0-ctrlbt-keys-feat-probe, 33bbdc9bc4d8, never merge): 84e76d4a69e34c0788d6bd68 FAILED: screen sh-3.2$, 10/10 keys consumed with "new-tab hold true". The bug is on feat. #29530's own 3 tests pass on that tip because they do not go through the router.

Observed / Not run

  • Observed: red 6577bde0 and green fd2b6cd4 above (read in their logs), the probe 84e76d4a above. Also on the dogfood line, green ba18fd57d338ad5d7c6b801c at the #29530 port head failed the same end-result check (screen sh-3.2$, 10 of 10 keys consumed by the router, creation hold count 0).
  • Not run: other entrypoints (Cmd-T, palette New Terminal, Ctrl-from a Home field) go through the sameCreationInputCoordinator.begin` seam and were checked by reading only.

Changelog

  • Fixed: keys typed right after Cmd-N then Ctrl-` (or Cmd-D) go to the new terminal, not the New Tab page.

No capture: key routing fix; evidence is the display-worker end-result test.
perf claim: none.