Fix flaky persist-scroll-position gesture test#5607
Open
habdelra wants to merge 1 commit into
Open
Conversation
…sition test `records the offset only after a genuine user scroll gesture` flaked: a programmatic `scrollTop` assignment fires its `scroll` event on the next rendering frame, not synchronously, and `settled()` does not await that frame. The gesture-less scroll set to 90 could therefore land during the subsequent `await triggerEvent(scroller, 'wheel')` settle — after the wheel flipped the modifier from restoring into recording — and be recorded as a spurious user offset, so `recorded` became `[90, 120, ...]` and the `every(v === 120)` check failed. Confirmed by logging: `onChange 90` fired between the pre-wheel and post-wheel markers. Await one animation frame after the gesture-less scroll so its event drains while there is still no gesture (and is correctly ignored). Also surface the recorded array in the assertion message so any future miss is diagnosable. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
burieberry
approved these changes
Jul 24, 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
2 participants
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.
Integration | modifier | persist-scroll-position: records the offset only after a genuine user scroll gestureis flaky — it surfaces on host shards (whichmainCI skips, so it goes unnoticed there) and reproduces locally under load at roughly a two-in-three failure rate.Root cause
A programmatic
scrollTopassignment fires itsscrollevent on the next rendering frame, not synchronously, andsettled()does not await that frame. The test's gesture-less phase setsscrollTop = 90(asserting it is not recorded, since no gesture has happened). That assignment's nativescrollevent stays pending. Under load it lands during the followingawait triggerEvent(scroller, 'wheel')settle — after the wheel has flipped the modifier from restoring into recording — so the modifier records90as a user offset.recordedbecomes[90, 120, …]and theevery(v === 120)assertion fails.Confirmed by logging each
onChangeand the wheel boundary: on a failing run,onChange 90fires between the pre-wheel and post-wheel markers.Fix
Await one animation frame after the gesture-less scroll, so its pending
scrollevent drains while there is still no gesture — the modifier ignores it, as intended — before the wheel switches on recording. The recording path is otherwise unchanged.Also surface the
recordedarray in the assertion message, so if this ever regresses the failure output names exactly what leaked instead of a bare boolean.Verification
Reproduced the failure locally (full-module run under load), then confirmed the fix: 5 consecutive green full-module runs, and the single test green in isolation. The drain consumes precisely the event that was leaking.
🤖 Generated with Claude Code