New Tab: Cmd-T shows the page at once again (the parked Chromium spare paints)

Merged
TE
6d ago
+56-3

Leo: "the rendering of the fing new tab page" / "MAN WE FINGKNOW WHAT THE NEW TAB PAGE LOOKS LIKE HOW CAN IT BE F***ING SDLOW"

Cause

Cmd-T adopts a prewarmed New Tab page (the spare), parked in a fully transparent view 100000 pt off screen. Since #28002 (10-30), PageWebView.setChromiumVisibility hides a Chromium page whenever an ancestor is transparent, so its child window cannot float over a paint hold. That rule also caught the spare's parking. The New Tab page runs in Chromium by default, so the spare never painted while parked. Cmd-T then adopted a page that had not painted, the pane's PanePaintHold kept the old tab on screen waiting for a first frame that a hidden page never draws, and the New Tab page showed only when the hold's 500 ms limit ran out. Trace of a warm Cmd-T on base: hold_begin 34 ms, hold_end 547 ms, page_painted 552 ms.

Fix

A marker protocol PageChromiumOffscreenParking (CmuxNextPages). NewTabSpareParking adopts it, and setChromiumVisibility ignores that one ancestor's alpha. The parking already sits outside the window's content, so the page draws off screen and nobody sees it. Every other transparent ancestor still hides Chromium, so #28002's stale-composer fix stands. No design change. No new timers or observers.

Performance

Same fleet capture mini, one lease, base 9b6c2181 and head 2206b68f built by the fleet (Debug, CEF bundled, default settings so the page shows in Chromium), run back to back. Cmd-T from a terminal tab, 8 openings per arm. warm = a ready spare; cold = the spare dropped just before Cmd-T.

metricbeforeafterdeltaharness or run link
Warm Cmd-T: pane paint hold (old tab kept on screen)542 ms (hold_begin 14, hold_end 556)none: the adopted page already painted-542 msdebug.chat_open_trace around one Cmd-T
Warm Cmd-T: old tab leaves the content area, p50 / p90 / max547 / 549 / 565 ms4.5 / 11 / 15 ms-542 ms p50debug.new_tab frame_strip, settled_ms, n=8
Cold Cmd-T (spare dropped), p50 / p90 / max540 / 552 / 557 ms6.5 / 7 / 7 ms-533 ms p50same, n=8
Blank or in-between content frames000same

The window capture leaves out Chromium's child window, so frame_strip sees the old tab leave but not the page arrive. Real screen captures (screencapture, child windows included) about 160 ms after Cmd-T, three per build: head shows the finished New Tab page (field, folder and machine chips, model) every time; base still shows the previous tab, and shows the New Tab page only in the 1 s capture, with its model chip still a placeholder. Not attached because they show fleet host names.

Before #28002 (10-29 benches at 03722e14) warm Cmd-T was about 100 ms key-to-visible, so this takes that regression back out without undoing #28002's paint-hold rule.

Tests

  • AgentPaneChromiumVisibilityTests.anOffscreenParkingKeepsAParkedSpareDrawing (a parked Chromium spare stays visible to Chromium; a transparent paint-hold ancestor still hides it) and NewTabSpareParkingChromiumTests. Red at f811791 (test commit, observed on the fleet: both fail, the parked spare reports hidden and the parking does not conform). Green at the head: not run yet. The fleet step queued for 2.5 h without starting (Blacksmith overflow timed out, then the targeted Macs paused claims); it stays queued as a follow-up. At the head, the app compile and fleet test-compile passed, and the head build gave the measured numbers above.

Changelog

Fixed: The New Tab page shows right after Cmd-T again, instead of half a second later.

risk: normal.

No capture: same pixels as before, only sooner; the frame-strip numbers above measure it.

Agent session: agent session

šŸ¤– Generated with Claude Code