Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
OS-jacobbell
approved these changes
Jul 28, 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
3 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.
Issue number: internal
What is the current behavior?
The shared
dragElementByPlaywright helper (core/src/utils/test/playwright/drag-element.ts, used by every gesture e2e test) unconditionally runsawait page.evaluate(() => window.getSelection()?.removeAllRanges())betweenmouse.down()and the drag movement. That line was added in #31260 to clear a Firefox-only text selection, but the extrapage.evaluate()is an awaited round-trip that injects variable latency into the gesture path for all browsers. On WebKit that latency messes up the gesture's timing-derivedvelocityX, so theitem-slidingsafe-area screenshot tests in md mode settle a few pixels off and flake randomly. Since it lives on main, the flake has propagated to every other branch (next and major-9.0) and causes random test failures in PRs and nightlies.What is the new behavior?
The selection clear now only runs on Firefox, which is the only engine that needs it (the existing comment already scoped the problem to Firefox). Chromium and WebKit skip the extra round-trip and get the same drag timing they had before #31260, so the item settles deterministically and the flake goes away. This matches the
browserType().name() === 'webkit'gate already used elsewhere in the same file.Does this introduce a breaking change?
Other information
Regression was introduced by #31260 (the
removeAllRangesline, not the modal a11y change itself). Verified by running in docker locally several times.