test(browser): hold motion when it commits, not on its start event

[loganj]

🤖

Summary

• Two browser tests sometimes failed on Linux WebKit CI and then passed when the same commit ran again. The sidebar test failed with "Missing sidebar transition" (sidenav-polish.spec.mjs:337). The mention test at mentions.spec.mjs:594 checks a short reveal animation in the same way, so it can fail for the same reason.
• Both tests freeze a short CSS motion (about 220ms) so they can check the middle of it. Until now they froze it when a "motion started" browser event arrived (transitionrun or animationstart). WebKit can send that event one frame late. If that frame is slow, the motion has already finished, so there is nothing left to freeze and the test fails. In the sidebar, other small transitions inside the sidebar (the resize handle) also send transitionrun up to the same listener.
• Now each test freezes the motion when the page changes the attribute that starts it: aria-hidden on the sidebar, data-reveal on the mention qualifier. The browser creates the motion as part of that change, so the test holds it before any frame can run. No product code changes.
• Fix flaky WebKit menu focus browser test #409 fixed the same kind of failure in menu-dismiss.spec.mjs in the same way.

Details

• getAnimations() makes the browser compute styles right away. When the test calls it inside the attribute-change callback, the new transitions already exist and can be paused.
• The late event does not happen on demand on macOS. To check the fix, I made the old event arrive after the motion had finished. The old tests then failed on both Chromium and WebKit, and the new tests passed. Without that change, both the old and new versions passed 20 repeated WebKit runs locally, so Linux CI is the real check.
• Both changed files pass in full on Chromium and WebKit locally.
• Not included: three tests in tests/fixtures/design-system/viewer.spec.ts also freeze motion from transitionrun. They filter by target element, so the bubbling problem does not affect them, but a late event still can. They have not been seen failing in CI, so I did not change them here.

[wesbillman]

No actionable source findings: the observers hold real motion at its DOM commit while retaining interpolation, clipping, reduced-motion, and recovery assertions.

Hosted CI passed on attempt 2 (the first attempt had cancellations); the affected files passed in both engines, but repeat-run flake elimination is not established.

Source-only: I ran no tests/apps, and did not establish comparative timing improvements or native acceptance; Windows validation was skipped.

Star Lord’s automated review via Wes’s account — head 161cc909d4708236d4f426ea70ff2b583ac06ec3, base 9ab4a1792b0d2cc60c9734baf1dc45911ee8bc83; COMMENT only, not approval.

[kalvinnchau]

Code-only review: no blockers.

Both flake fixes replace start-event listeners (transitionrun / animationstart) with a MutationObserver on the attribute/style commit, matching the menu-dismiss #409 pattern. The sidenav observer on aria-hidden is exactly the style change that creates the max-width/clip-path transitions, and nav.getAnimations() excludes descendant transitions, so both old failure modes (bubbled descendant transitionrun, late dispatch after the 220ms transition finished) are closed. The mentions observer holds the reveal when data-reveal renders and pauses only matching animationName, preserving the qualifierReveals.length === 2 hold guarantee.

Deferred check: Linux WebKit CI green on this head is the evidence the mutation-microtask getAnimations() flush holds; a green run here should complete it.