Andreas Reinhold / reiniandClaude Opus 5
94d6e31432
tests / feature (8.4) (push) Successful in 1m45s
tests / feature (8.5) (push) Successful in 2m0s
tests / browser (chrome, chromium) (push) Successful in 8m6s
tests / browser (firefox, firefox) (push) Failing after 12m52s
tests / browser (safari, webkit) (push) Failing after 13m1s
The browser suite passes on every engine here and fails on the runner, which takes three times as long: each failing test triggers a close and then samples for an in-between state — a rail part-way out, a scrim part-way faded, a menu's exit copy part-way sunk — and a starved runner takes its one sample after the 150-650ms exit has already finished. So the tests that assert *that* something animates now stretch every motion duration token to three seconds first (`slowMotion()`, beside `ready()` in tests/Pest.php; ActionsTest's own copy of it goes). The two polling helpers grew their budget to match: the rail panel and the sheet slide on emphasized-accelerate, which is under 1% of its travel at a quarter of the way through, so a 300ms window no longer reached the threshold once the exit itself was three seconds long. The two full-screen date picker tests waited for a resize through click()'s own retry, which ate the whole 15s budget on Firefox; they now wait for the new width and a settled document first. The bottom sheet's preset test waits for its entry to finish before pressing the grip. `hold()` in search.js reads the view's animations a frame after the closed state, as the rail's settle() does, but one frame is not always enough: an engine that starts them on its next tick shows none, and the full-screen layout would end at once, mid-exit. An empty list is now asked again on the following frame. Feature 1159 passed. Browser 299 passed on Chrome, Firefox and WebKit, and again on WebKit under ten spinning cores. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>