Repository navigation
spec(AST-094): a scroll-edge pan may hold the rubber band from the first move (FR19, D28) - #8628
Conversation
…e first move (FR19, DEC-18)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
|
/approve-spec df7d9fa |
github-actions
Bot
added
the
spec-auto-merge
PR Analysis Report
|
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.
One small change is needed: the FR19 amendment and DEC-18 have an engineering owner's approval for this head, but the FR18–FR22 verification row (docs/specs/AST-094-touch-presentations/spec.md, line 549) still fails "a cancelled unowned touchmove outside FR19's two exceptions" while FR19 now lists three, so the row fails the scroll-edge cancel the new exception allows. Change "two" to "three" there; a new commit invalidates the current approval, so an engineering owner (the author is one) then re-approves with /approve-spec <full head SHA>.
- Optional: FR14 describes the same pull as "the drag moves toward that edge" while the new FR19 text says "the finger moves away from that edge", and using FR14's wording would prevent a misread.
- Optional: DEC-18 says the browser rubber-bands before 10 pt but names no browser or measurement, while FR2's Mobile Safari measurement keeps
touchmovecancelable through 10 px, so naming the source or marking it a guess would close that gap.
[Automated review]
| | FR13 | Resolver unit tests and a server-render test | coarse and fine pointer; narrow, wide and short; server render; hydrating render | a component that answers the conditions differently, or a touch presentation in the server or hydrating render, fails | | ||
| | FR14 | Browser tests of a sheet over a scrolled list | scrolled and at its top | a midway handoff fails | | ||
| | FR15–FR17 | Recognizer unit tests on synthetic streams with explicit timestamps | exclusive, simultaneous, require-to-fail, nested; a watcher beside a claiming winner; a blocked main thread; a pan at 10 pt per axis | a wrong winner, a late deadline, or a translation that keeps the hysteresis, or a watcher failed or cancelled by a claiming winner fails | | ||
| | FR18–FR22 | Browser tests with real touch input (`spec:AST-013` FR10) | per-axis pans beside native scrolling, page zoom, cancelled touches, clicks after taps, keyboard activation, a modal scroll lock, a control that keeps its press through a drag; a still finger with sub-pixel jitter over a scroll view; a finger moved 9 px and 10 px straight, and (7, 7) and (8, 8) diagonally; a recognizer on an element whose author `touch-action` is narrower, including one without `pinch-zoom`; a screen-edge pan landing at 40 px and at 41 px from the edge, at 14 px and 15 px of travel, and a horizontal scroll that starts outside the band; a sheet's pull from a list at its top, and from a list scrolled away from its top | a ghost click, a scroll or zoom blocked other than by the author's `touch-action`, or a cancelled unowned touchmove outside FR19's two exceptions, a tap cancelled by sub-pixel movement or by under 10 px of travel, a scroll that does not take the touch at 10 px, or a derived `touch-action` wider than the author's, a screen-edge pan that claims outside its band or before 15 px, or has not claimed at 15 px, or an author scroll outside the band that is blocked, or a scroll-edge pan that cancels a move a scroller could scroll, or begins before 10 pt, fails | |
There was a problem hiding this comment.
This row's failure text still reads "a cancelled unowned touchmove outside FR19's two exceptions", but FR19 now lists three (line 269). Read literally, the row fails the scroll-edge cancel that the third exception allows. "FR19's three exceptions" (or "FR19's exceptions") keeps the row in step with FR19.
| cancel that finger's moves. A scroll-edge pan, such as a sheet's pull | ||
| from a scroll area at its edge (FR14), MAY cancel its touch's moves from the | ||
| first move, only while every scroller under the finger sits at its edge and | ||
| the finger moves away from that edge, and only the moves the browser would |
There was a problem hiding this comment.
Optional: FR14 (line 224) describes this same pull as "the drag moves toward that edge", while this line says "the finger moves away from that edge". The clause that follows pins down the behavior, but FR14's wording would keep the two claims from reading as opposite cases.
… scroller under it is at the edge spec:AST-094 FR19 and DEC-18 (proposed in meta#8628): a scrollEdge pan may cancel its touch's moves from the first one, only while every scroller under the finger sits at its edge and the finger moves away from it, and only the moves the browser would rubber-band; it still begins at FR17's 10 px. The first case reads the first 2 px move cancelled at the edge and fails on this head; the others keep what must not change: room to scroll leaves every move to the browser, a first move toward the content too, a pan without scrollEdge cancels nothing before it begins, and a touch the browser took for a scroll stays the browser's when the list reaches its edge.
… cancelled at the edge spec:AST-094 FR19 and DEC-18 (proposed in meta#8628). The sheet's scroll-edge pan at the top of its content: every touchmove the page sees is cancelled, the first one included. WebKit sends that first move at 2 px, before the sheet's 10 px begin, and it reaches the page uncancelled on this head; Chromium sends none inside its own 15 px slop, so there it proves only that nothing scrolls.
…e away from an edge spec:AST-094 FR19 and DEC-18 (proposed in meta#8628). GestureRecognizer gains keepsTouch(touchId), false by default and reached by the host through recognizerInternals: whether it holds that finger before it begins. A scrollEdge pan does while it is possible, the touch is a finger the browser has not taken, its travel so far goes the pan's own way, and no scroller under the finger can scroll for it (the probe its begin already reads), so only moves the browser would rubber-band are held, never a real scroll. The host's blocking touchmove check cancels a move a participant holds, as it does a claimed one; the arena already holds that move when the check runs, since the host feeds it from its window-capture subscriber first. The pan still begins at 10 px; a mouse or a pen is never held. The README says so.
|
/approve-spec e42ad37 |
There was a problem hiding this comment.
This looks ready to merge: FR19's scroll-edge exception, the extended FR18–FR22 verification row and DEC-18 have an engineering owner's approval for this exact head, and the row's count and FR19's wording now match FR19 and FR14. Two optional follow-ups would help whoever implements it: DEC-18 labels its premise that Mobile Safari rubber-bands before the pan's 10 pt start as unmeasured, so naming the simulator measurement that would settle it (as DEC-14 does) would close that gap, and the row could list a tap with sub-pixel jitter on a list at its top, where the new permission meets the existing "tap cancelled by sub-pixel movement" failure. Whichever of this and the pull requests adding DEC-15 to DEC-17 lands second will need a rebase of the decision log.
[Automated review]
…s from its first move spec:AST-094 FR19 and DEC-18, as proposed in meta#8628: at a scroll edge, a pull away from it may hold its touch's moves from the first one, only while every scroller under the finger is at that edge, and never a real scroll; the pan still begins at 10 px. The body's pans are scroll-edge pans, so F2's meta#8336 (the recognizer's keepsTouch, carried by meta#8320) gives the sheet that with no code of its own. The body's pull test now holds its first moves (it fails when the scroll-edge pan keeps no touch: the first move at 3 px reaches the browser) and still begins the pan at 10 px; two guards pass either way: a list that can still scroll keeps every move, and a first move toward the content is the browser's even at the top.
Decided (Cindy, 2026-10-26, D28 = a).
User impact
On a phone, pulling a sheet down from a list that's already at its top moves the sheet at once, as iOS's sheet pull does, instead of the page rubber-banding first. A real scroll is never blocked.
The trade-off, recorded in DEC-18: a list inside a sheet can't pull to refresh from its top.
Change:
spec:AST-094FR19Writing rubric results