Repository navigation
Conversation
… that finger until it lifts (spec:AST-094 FR14) A recognition that claimed its touches and was then cancelled gave them back to the browser unless another recognition owned them, so a finger resting there could pinch-zoom the page. A gesture that cancels itself on a finger's move, a long press dragged past its tolerance after it began, gave back a finger that was dragging: the host stopped cancelling its moves and the page scrolled the rest of the drag, a hand change FR14 forbids and UIKit never makes (its scroll view never takes a touch another recognizer had). A cancel during a finger's move now keeps that finger claimed until it lifts; a resting finger is given back as before, and a waiting recognition that fails still gives its claim back. The new arena case fails on the previous code: the dragging finger reads unclaimed right after the cancel.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
meta-cla
Bot
added
the
CLA Signed
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Recommending approval: keeping a finger claimed until it lifts when its gesture is cancelled during that finger's move follows spec:AST-094 FR14, and the resting-finger and waiting-recognition releases stay as they were. The new arena test fails without the change and passes with it, and the gestures suite, core typecheck, lint and changeset check pass. Optionally, the releaseClaim comment could describe the rule as a gesture cancelled during a finger's move: a cancel() made from a listener during the move keeps the moving finger too, while the comment still lists a gesture the app cancels among those that give their touches back.
[Automated review]
| * cancels) gives them back to the browser unless another recognition owns | ||
| * them, so a finger still resting there can pinch-zoom the page. | ||
| * them, so a finger still resting there can pinch-zoom the page. A gesture | ||
| * that cancels itself on a finger's move (a long press past its tolerance) |
There was a problem hiding this comment.
Optional wording: the keep follows the move being delivered, not who cancels, so a cancel() made from a changed listener during the move keeps the moving finger too, while line 550 still lists a gesture "the app cancels" among those that give their touches back. "A gesture cancelled during a finger's move" would match the code.
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewNo new or modified components detected. Bundle Size SummaryGzip figures measure each package's entry file, not the code an import pulls in.
Accessibility AuditStatus: No accessibility violations detected. Visual Regression55 of 502 shot(s) changed. A change here is a question, not a failure: check whether the after is the
and 35 more. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
User impact
On a phone, a gesture that claims its finger and then cancels itself on one of that finger's moves hands the rest of the drag to the page. The visible case: a touch ContextMenu trigger held past its long press's commit, then dragged past the press's tolerance before the menu is due. The press cancels itself and the page scrolls with the finger, a drag that changes hands midway.
Problem and solution fit
spec:AST-094FR19), so the host stops cancelling that finger'stouchmove, and a finger that is dragging becomes the page's scroll.The fix keeps the release for a resting finger and stops it for a moving one.
Expected behavior and authority
spec:AST-094FR14 (current). The case was raised on #8058 as a question (issuecomment-6408527888): should a gesture that cancels itself on a finger's move keep that finger claimed until it lifts, with the release kept for a resting finger?Smallest restoration
GestureArena: a cancel during a finger's move keeps that finger claimed until it lifts. A resting finger is still given back when its gesture is cancelled (the pinch case), and a waiting recognition that fails still gives its claim back. One arena change, its test and a changeset.Evidence
a drag that cancels the press after the commit does not scroll the page either(a hold past the commit, then a 200 px drag) scrolls the page 190 px in Chromium on every run.arena.test.tscase fails on main (the dragging finger reads unclaimed right after the cancel) and passes with the fix.Scope
Testing
pnpm exec vitest run --project ui packages/core/src/gestures: 113 passed on main bb24260 with this commit; the new arena case fails without it.tsc --project packages/core/tsconfig.json --noEmit,ASTRYX_STRICT_LINT=1 eslint packages/core/src/gestures/GestureArena.ts packages/core/src/gestures/__tests__/arena.test.ts,pnpm check:changesets: clean.