[nstepien]

Experiment, not to be merged. Follows up on #4232: why does a WebKit page stop responding for seconds on Linux CI?

In run 40029118938, the focus click in test/setupBrowser.ts timed out while Playwright waited for the page itself, right after the million-row TreeDataGrid test, and after that grid had unmounted. That test bloats WebKit's web process by ~1.1 GB, and ~0.6 GB stays committed afterwards. One hypothesis is Linux WebKit's memory-pressure handling, which would release memory on the page's main thread every so often. Locally, Windows WebKit pages also stalled for over 2 s twice, in tests that didn't follow the million-row test.

The WebKit stall experiment workflow runs three times, each with:

1. zzStall.experiment.tsx: renders a million rows, then idles for 65 s, then does the same with 100k rows as a control.
2. The whole WebKit suite.

Both steps load test/zzStallSampler.ts, which records every main-thread stall over 100 ms in each page, with wall-clock times and the test that was running, and prints them once per file as STALLS {…}. A background loop samples the RSS of WebKit's web processes every 200 ms, with millisecond timestamps. The logs are uploaded as artifacts.

Reading it:

• Memory pressure is likely if stalls of a second or more line up with RSS drops of a web process, at regular intervals while it stays above ~1 GB, after the million rows but not after 100k.
• A cross-page effect is likely if stalls in the suite line up with the million-row test running in another page.

The regular CI workflow doesn't set the experiment's environment variables, so it runs as usual.

Results

	Run 1	Run 2	Run 3
Stall while rendering a million rows	1.57 s	1.46 s	1.44 s
Stalls while idle for 65 s afterwards	none	none	none
Web process memory, peak → after the render	1.50 → 0.97 GB	1.59 → 0.97 GB	1.59 → 0.96 GB
Longest stall in the suite, in the million-row test	3.11 s	3.59 s	2.87 s
Next longest stall in the suite	0.64 s	0.59 s	1.56 s

• Memory pressure: not supported. The page didn't stall at all while idle after the million rows, and the web process's memory stayed flat. The release from ~1.5 GB to ~1 GB happens right after the render.
• Cross-page effect: none. No long stall in another page overlapped the million-row test.
• The million-row test blocks its page's main thread for ~3 s, by far the longest stall in WebKit's suite. The next longest come from virtualization.test.ts's tests with virtualization disabled.
• All 205 WebKit tests passed in each run, so the original stall, after the million-row test had ended, didn't reproduce.

🤖 Generated with Claude Code