Repository navigation
spec(AST-094): a cancelled moving touch stays with its recognizer (FR19) - #8978
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
/approve-spec e9df8b6 |
|
AI review status for this pull request.
|
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Changes requested for one wording fix; the direction itself is owner-approved and the record passes the knowledge check. The new FR19 sentence applies to any recognizer "cancelled while its touch is moving", which also covers the active recognizers FR20 cancels when the browser takes a moving touch, so the record would give that touch both to the recognizer and to the browser. Since the description keeps FR20 unchanged, scoping the subject (for example "…, other than by the browser taking that touch (FR20), …") resolves it, and naming the waiting recognizer as FR15 does ("a recognizer that requires another to fail") keeps the sentence in the record's own terms. A new commit needs a fresh /approve-spec on its head.
[Automated review]
| A recognizer that is cancelled while its touch is moving, such as a long | ||
| press dragged past its tolerance after it began, keeps owning that touch | ||
| until it lifts and MAY cancel its moves, so the drag never becomes a page | ||
| scroll midway (FR14); a touch that is resting when its recognizer is | ||
| cancelled, and every touch of a waiting recognizer that fails, is given back | ||
| (FR10). A |
There was a problem hiding this comment.
FR20 overlap. This subject covers any recognizer "cancelled while its touch is moving", which includes the active recognizers FR20 (lines 319-324) cancels when the browser takes a moving touch: pointercancel, an uncancelable touchmove, or a native scroll past the take distance. For those, this sentence says the recognizer keeps owning the touch and the drag never becomes a page scroll, while FR20 says the browser already has it. The description keeps FR20 unchanged, so scoping the subject resolves it, for example: "A recognizer that is cancelled while its touch is moving, other than by the browser taking that touch (FR20), …". "A waiting recognizer" also appears nowhere else in the record; FR15's "a recognizer that requires another to fail" would name it, and the two subjects take "are given back".
…hes FR15's wording
github-actions
Bot
added
the
needs:spec-owner-review
PR Analysis Report
Generated by PR Enrichment workflow | View current CI run |
There was a problem hiding this comment.
Approval waits on an engineering owner's decision for this head: the latest push rewords FR19's new exception, and the earlier /approve-spec named the previous commit, so it no longer applies. The rewording resolves the earlier overlap with FR20, the record passes the knowledge check, and nothing else needs to change. To settle it, an engineering owner comments /approve-spec <full head SHA> on this pull request to approve FR19's fourth exception and the new FR18–FR22 case as worded, or asks for different wording; the author can do this as an engineering owner.
[Automated review]
… the browser (FR20) (#8456) ## Decision `spec:AST-094` FR20: only a finger's first uncancelable `touchmove` counts as the browser taking the touch, and only when the browser could scroll along the finger's main axis. The main axis is the one the finger has moved farther along since touch-down, horizontal on a tie; the browser could scroll along it when a scroller under the touch has room that way and every `touch-action` between them allows that pan (FR18). Later uncancelable moves of that finger never count. `pointercancel` and a native scroll past the 10 px take distance count as before. One verification row covers a horizontal drag under `pan-y`, a vertical drag under `pan-y` over a scroller with room, and a vertical drag where no scroller has room. ## Why Chromium stops letting a page cancel touchmoves after the first one it does not consume, even on an axis `touch-action` forbids (a horizontal drag under `pan-y`). Counting every uncancelable `touchmove` therefore drops every sideways swipe inside a vertically scrolling page (a carousel, a swipe row) on Android before it reaches its 10 px start. A real browser pan still reports through `pointercancel` or the scroll. The gesture host in #8071 already judges the first uncancelable move this way. Credit: @vjeux measured the Chromium behavior and proposed the rule. ## Existing authority searched - `spec:AST-094` FR20 (current), FR18, FR2/DEC-8 (10 px scroll take distance), FR19. - Overlap: #8978 edits FR19 and re-pads the verification table; whichever merges second rebases. ## Rejected alternatives - Counting every uncancelable `touchmove`. ## Writing rubric results - R1 narration: none. - R2 research in the record: none; the Chromium measurement stays in this description. - R3 evidence naming a change: none. - R4 rejected alternatives over one line or outside a decision: none. - R5 pull request or issue references remaining: none. - R6 ruled open questions still listing options: none. ## Scope - [x] This PR contains specification records only: one FR20 sentence and one verification row. - [x] It records observable behavior and preserves equivalent internal implementations. - [x] Public text contains no internal context. ## Validation - `pnpm check:knowledge` - Prettier
…ncel # Conflicts: # docs/specs/AST-094-touch-presentations/spec.md
There was a problem hiding this comment.
Approval waits on an engineering owner's decision for this head: the merge from main is a new commit, and the only /approve-spec on this pull request names an earlier one, so it no longer applies. The FR19 wording is unchanged by the merge, the record passes the knowledge check, and the new exception still fits FR20 as amended on main, so nothing else needs to change. To settle it, an engineering owner comments /approve-spec <full head SHA> to approve FR19's fourth exception and the new FR18–FR22 case as worded, or asks for different wording; the author can do this as an engineering owner.
[Automated review]
|
/approve-spec 8ca2703 |
github-actions
Bot
removed
the
needs:spec-owner-review
There was a problem hiding this comment.
This spec change is ready to merge: an engineering owner approved FR19's fourth exception and the new FR18–FR22 case at this head, and the record passes the knowledge check and Prettier. The earlier overlap with FR20 is resolved by excluding the browser's take from the new exception, and nothing else needs to change.
[Automated review]
Exact decision needed
On a phone, someone holds a message to open its menu, then drags away. The hold cancels itself on that move, and today the rest of the drag becomes a page scroll: the list jumps under a finger that was holding still. Does a gesture that cancels itself while its finger is moving keep that finger until it lifts?
Existing authority searched
spec:AST-094FR14 (current): who gets a drag is decided once and never changes hands midway.spec:AST-094FR19 (current): only an owner may cancel a touch's moves, with three listed exceptions. Whether a cancelled recognizer still owns its moving touch is not stated, so FR14 and FR19 point different ways for this case.spec:AST-094FR10, FR12, FR15 and FR20 (current), read for pinch-zoom, the long-press tolerance, arbitration and the browser taking a touch; none settles it.Decision
FR19 gains a fourth exception: a recognizer cancelled while its touch is moving keeps owning that touch until it lifts and may cancel its moves, so the drag never becomes a page scroll midway (FR14). A touch resting when its recognizer is cancelled, and every touch of a waiting recognizer that fails, is still given back, so the page keeps pinch-zoom (FR10). The FR18–FR22 verification row gains the case of a long press dragged past its tolerance after it began.
Rejected alternatives
Claim scope and non-goals
Evidence and implementation relationship
Writing rubric results
Scope
Validation
pnpm check:knowledge: aligned.git diff --check: clean.