Repository navigation
Skip the million-row TreeDataGrid test in WebKit - #4232
Merged
Merged
Conversation
WebKit lays out each row track of the grid, so the million rows of this test take ~250ms per layout and ~1 GB of memory, over half of which the page keeps. The tested code doesn't depend on the browser, and Chromium and Firefox have lower argument limits. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
nstepien
changed the title
TreeDataGrid test in WebKit
This was referenced Oct 25, 2026
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.
The "should expand a group with more rows than a function call can take as arguments" test renders a million rows, which is far more work for WebKit than for other browsers. DataGrid declares one grid row track per row (
repeat(${rows.length}, …px)inuseViewportRows), and WebKit lays out each track, while Chromium handles therepeat()as a whole. Measured locally:About 0.6 GB of that memory stays committed after the grid unmounts, for the rest of the page's life, and pages run several test files. In CI, the test takes 2.5–5.4 s in WebKit.
The only WebKit flake in CI since October 19, the focus click in
test/setupBrowser.tstiming out in run 40029118938, came from the test that ran right after this one: replaying the run's seed shows the order. The page didn't respond for over 2 s, after the grid had already unmounted. A Linux CI experiment in #4234 didn't reproduce that stall, but showed that this test blocks its page's main thread for 2.9–3.6 s, by far WebKit's longest stall in the suite (the next longest take 0.5–1.6 s), and that pages don't stall while idle afterwards. Locally, two other pages stalled for over 2 s in tests that didn't follow this one, so this change may not remove every stall. It does remove WebKit's longest main-thread block, and the memory that test leaves behind.The test still runs in Chromium and Firefox. It guards against spreading the rows into a function call, which doesn't depend on the browser, and their argument limits (123,758 and 500,000) are well below a million.
Separately, the same layout cost slows scrolling in WebKit with many rows: 186–230 ms per scroll step at 1M rows and 30–44 ms at 100k, against 8–15 ms in Chromium. That's worth its own issue.
vp run cipasses.🤖 Generated with Claude Code