[nstepien]

Firefox and WebKit tests are flakier than Chromium tests. One example is the WebKit locator.click timeout on the focus click in the beforeEach of test/setupBrowser.ts, which failed 2 of 5 local vp run ci runs in one session and has never reproduced on a rerun. The Firefox and WebKit instances now set retry: 1, so a failed test runs once more, beforeEach and afterEach included.

• Chromium doesn't retry, so flakes caused by the grid itself still fail there.
• A test that fails consistently fails on both attempts, so only intermittent failures pass.
• On GitHub Actions, Vitest adds the github-actions reporter, whose job summary lists the tests that passed on retry ("passed on retry 1 out of 1"). Vite Task passes GITHUB_* variables to tasks by default. Locally, --reporter=verbose marks them (retry x1), while the default reporter doesn't show them.
• --retry=0 doesn't override an instance's retry, as project options take precedence over CLI options. AGENTS.md now mentions this and --reporter=verbose.

I checked the config with a temporary test that fails only on its first attempt: it failed in Chromium and passed on retry in Firefox and WebKit, with and without --retry=0. vp run ci passes.

Production React builds

I also measured whether React's production build would make Firefox and WebKit faster. It wouldn't. Results for the whole suite, using the production build with a page.render that renders in flushSync, since production React has no act:

Browser	Wall time, dev → prod	Summed test time, dev → prod
Chromium	4.6 s → 4.6 s	24.7 s → 24.0 s
Firefox	46–48 s → 55 s	18–19 s → 16.3 s
WebKit	14.2 s → 13.8 s	106 s → 97 s

The tests mostly wait on Playwright actions and polling rather than on rendering, and the difference in Firefox's wall time is noise. The production build would also need a separate Vitest project, since browser instances share their parent's Vite config, plus a replacement for page.render, and it would hide React's development warnings in those browsers.

Firefox takes the longest for another reason: Vitest 5 runs projects that set fileParallelism: false in a group of their own, after all the other projects. Firefox therefore only starts once Chromium and WebKit are done, about 18 s into a 64 s run. Firefox with file parallelism still fails 7–8 tests per run, mostly mouse drags and focus checks, and several serial Firefox instances, each running part of the files, just run one after the other.

All timings are from local runs on Windows.

🤖 Generated with Claude Code