Fix Home dock Channels: the Chromium page gets the keyboard at its first open

Merged
LA
5d ago
+294-11

Summary

The docked Home's Channels page in Chromium never got the keyboard at its first open. The key window stayed the cmux window and its first responder stayed the hidden WebKit stand-in (PageWKWebView), so typing into Channels went nowhere until a click. Found by the journey found-desync-channels-type while covering a review case of #29272 (STATUS 1582).

Cause: TabContent.childWindowTab found a cmux page in Chromium only when a page tab's content IS the page. The docked Home is an internal page whose content is HomeDockView, and Channels is a page inside it. So for the dock the focus applier found no Chromium page. It took the page window's key change as unchosen, applied the model again, blurred Chromium pages and took the keys back for the cmux window.

Fix: a container view names the page it shows now (PageWebViewContainer; HomeDockView names Channels while Channels shows). childWindowTab finds it through PageWebView.shown(in:). The applier then gives the Channels page the keyboard as it does for any page tab in Chromium, and the page window's key change is the pane's own. Messages mode is unchanged (no page shows there).

Testing

  • Red first: PageWebViewShownInContainerTests (CmuxNextPagesTests), commit bf49e3f4d5a. Fleet step 03d1e6b8ebf66877cde96fa7 failed on its own assertion (PageWebView.shown(in: dock) → nil).
  • Green at acfd6110392: step 038ec695373a1987c1766761 passed PageWebViewShownInContainerTests, ChromiumPageFocusInvariantTests and PageWebViewChromiumTests.
  • Compile of the head: job 34a7e534fe7f6341d9424037 (CmuxNext with tests, app, cmux-tui) passed.
  • Journey scripts/journeys/journeys/fuzz/found-desync-channels-type.json (this PR adds the file; the harness lands with #29071). Run from a checkout of the harness branch, whole host, app active, through the mini scheduler (spec channels-keys-journeys), cmux20.

Observed / Not run

Observed:

  • feat base f2f3083bac80ab71101d03ac: the claim FAILS. Key window ShellWindow, first responder PageWKWebView (also on #29272's builds 568ad9fb and ed24b7b1, 12:09-12:20Z).
  • this head (build b101b874158569f03d3fe9e8): the claim HOLDS. Key window CefNSWindow, the applier's child page recorded, first responder not PageWKWebView. The journey still ends red, at its closing health check (a Cmd-N, then fuzz_daemon_agrees): G1: page window (618, 268, 892, 692) covers no pane. That is the false G1 that #29272 fixes; this branch is cut from feat without it. Once #29272 lands, that step is expected to pass.

Not run:

  • Typed keys into Channels: debug.key's sequence mode has no event timestamp on the capture minis, so the journey reads the focus state, not a typed character.
  • A Channels page opened as its own tab (home.channels): there the content is the page itself, which the old rule already covered.

Changelog

Fixed: Typing in Home's Channels view works the first time Channels opens, without a click first

Proof

No capture: there is no visual change; the change is which window holds the keyboard. The journey's frames are in its run folder.

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.

Summary by cubic

Fixes the docked Home's Channels view in Chromium never getting the keyboard at its first open, so typing into Channels works without clicking first.

The focus applier only found a Chromium page when the page tab's content is the page itself. For the docked Home, an internal page whose content is HomeDockView, Channels sits inside that view, so no Chromium page was found; the cmux window kept the keys and the hidden WebKit stand-in stayed first responder. A container view now names the page it shows (PageWebViewContainer; HomeDockView names Channels while Channels shows), and TabContent.childWindowTab finds it through PageWebView.shown(in:). The applier then gives the Channels page the keyboard like any other Chromium page tab. Messages mode shows no page, so it is unaffected.