Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
github-actions
Bot
added
the
needs:spec-owner-review
meta-cla
Bot
added
the
CLA Signed
806947d to
cc6508f
Compare
cc6508f to
0ea9be9
Compare
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
This pull request is on hold for an engineering owner's decision: it adds the draft spec:AST-094 and new component:Item requirements (FR9–FR13, AR3–AR5, ORD2–ORD3, PR2, DEC-3, DEC-4), and it describes the 8 px / 25 px swipe split as pending owner review. An engineering owner, including the author if they are one, can record approval by commenting /approve-spec <full head SHA> on this pull request, or say which of these deltas must change or land separately. Whatever that decision, these changes are still needed:
- Land the predecessor pull requests (or retarget the base) so this one carries only its own commit; it currently diffs 26,239 authored lines.
- A two-finger pinch that lands on two different swipe rows still does not zoom the page and opens both rows, contrary to the
item-swipe-pinch-zoomchangeset. spec:AST-057asks for physical touch-device evidence for FR5/FR6; the evidence so far is the iOS simulator and Chromium.- The unused
resolveReleasesays a flick never fires an action, which contradictsspec:AST-057FR5.
[Automated review]
| } | ||
| const target = touch.target instanceof Node ? touch.target : event.target; | ||
| const {recognizers, consumer} = this.participantsAt(target, 'touch'); | ||
| if (recognizers.length === 0 && consumer == null) { |
There was a problem hiding this comment.
A finger that lands on another swipe row is tracked only for that row's recognizers, so this row's one-finger pan never learns a second finger is down. A pinch across two rows is then claimed by both pans: the page does not zoom and both rows open (Chromium, Swipe Actions story: zoom 1.00, rows moved 146 px and 97 px). Failing a touch-only one-finger pan while another finger is down anywhere (TouchEvent.touches) before it claims would restore the hand-off the changeset promises.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [fix] A row with `swipeActions` no longer blocks pinch-zoom. A pinch that started on a swipeable `Item` or `ListItem` did nothing, because the row declared `touch-action: pan-y`, and a sideways pinch could also be taken as a swipe. The row now leaves pinch to the browser (`pan-y pinch-zoom`), and a second finger that lands before the swipe has begun, on the row or anywhere else, hands the touch to the browser, so the page zooms and the row stays where it is. One-finger swipes and vertical scrolling are unchanged. |
There was a problem hiding this comment.
"on the row or anywhere else" does not hold for a second finger on another swipeable row: there the page does not zoom and both rows swipe open.
| * it opens and closes it when it closes, from anywhere short of the commit | ||
| * point. A slower one goes by where it is, against `openFraction` of the | ||
| * open width. So a flick opens the row even from a short drag and closes it | ||
| * from anywhere, and a flick never fires an action: only a release past the |
There was a problem hiding this comment.
spec:AST-057 FR5 says a fling MUST fire the outermost entry; "a flick never fires an action" contradicts it. The swipe hook does not call resolveRelease, so drop it (with releaseVelocity and openFraction) or keep it out until FR5 is amended.
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewModified ComponentsItem (@astryxdesign/core) · View in Storybook
Component Size
Sizes are gzip. Import counts the JavaScript the import loads eagerly; CSS counts the package stylesheet rules referenced by the modules it can load from its own package, lazily loaded ones included.
|
| Component | JavaScript | CSS |
|---|---|---|
| core/BreadcrumbItem | +18.4KB |
0B |
| core/CheckboxListItem | +18.4KB |
0B |
| core/ContextMenu | +18.6KB |
0B |
| core/ContextMenuItem | +18.2KB |
0B |
| core/DropdownMenu | +18.1KB |
0B |
| core/DropdownMenuCheckboxItem | +18.2KB |
0B |
| core/DropdownMenuItem | +18.1KB |
0B |
| core/DropdownMenuRadioItem | +18.2KB |
0B |
| core/DropdownMenuSubMenu | +17.9KB |
0B |
| core/Item | +18.0KB |
0B |
| core/ListItem | +18.4KB |
0B |
| core/Markdown | +18.8KB |
0B |
| core/MoreMenu | +18.0KB |
0B |
| core/Pagination | +18.5KB |
0B |
| core/PowerSearch | +18.5KB |
0B |
| core/RadioListItem | +18.5KB |
0B |
| core/Selector | +19.1KB |
0B |
| core/SelectorOption | +18.1KB |
0B |
| core/Table | +18.5KB |
0B |
| core/TableCell | +18.5KB |
0B |
| core/TableHeaderCell | +18.5KB |
0B |
Bundle Size Summary
Gzip figures measure each package's entry file, not the code an import pulls in.
| Package | Entry (ESM) | Entry gzip before | Entry gzip after | Delta |
|---|---|---|---|---|
| @astryxdesign/core | 4.9KB | 1.2KB | 1.2KB | 0B |
| Package stylesheet | Gzip before | Gzip after | Delta |
|---|---|---|---|
| @astryxdesign/core | 34.6KB | 34.6KB | 0B |
Accessibility Audit
Status: No accessibility violations detected.
Visual Regression
55 of 504 shot(s) changed.
A change here is a question, not a failure: check whether the after is the
picture you intended. Record that review on the PR. Baseline maintenance is an
explicit dispatch of CI; this report never rewrites the baseline or adds a release gate.
| component | story | theme | mode | pixels |
|---|---|---|---|---|
| Selector | Indicator Space Bottom Sheet Narrow End RTL | neutral | light | 753,933 |
| Selector | Indicator Space Bottom Sheet Wide Start | neutral | light | 740,072 |
| RichTextEditor | Markdown parity: side by side | probe | dark | 558,840 |
| RichTextEditor | Markdown parity: side by side | probe | light | 540,756 |
| Chat | Full AI Chat | probe | light | 230,823 |
| Chat | Full AI Chat | probe | dark | 229,805 |
| AppShell | With Mobile Nav | probe | light | 217,010 |
| AppShell | With Mobile Nav | probe | dark | 216,960 |
| Collapsible | Dividers | probe | dark | 66,445 |
| Collapsible | Dividers | probe | light | 66,445 |
| AppShell | Playground | neutral | dark | 65,198 |
| AppShell | Playground | neutral | light | 63,788 |
| Chat | Default | neutral | dark | 36,304 |
| Chat | Default | neutral | light | 35,767 |
| Chat | Empty State | probe | light | 23,531 |
| Chat | Empty State | probe | dark | 22,622 |
| ChatAutoScroll | Scroll Behavior Comparison | neutral | dark | 15,378 |
| ChatAutoScroll | Scroll Behavior Comparison | neutral | light | 14,107 |
| Chat | With Attachments | probe | light | 13,406 |
| Chat | With Attachments | probe | dark | 11,232 |
and 35 more.
Generated by PR Enrichment workflow | Storybook | Sandbox | View full report
0ea9be9 to
291b98e
Compare
There was a problem hiding this comment.
This pull request is on hold for an engineering owner's decision: it adds the draft spec:AST-094 and new component:Item requirements (FR9–FR13, AR3–AR5, ORD2–ORD3, PR2, DEC-3, DEC-4), and it calls the 8 px / 25 px swipe split pending owner review. An engineering owner, including the author if they are one, can record approval by commenting /approve-spec <full head SHA> on this pull request, or say which of these deltas must change or land separately. Whatever that decision, these changes are still needed:
- Land the predecessor pull requests (or retarget the base) so this one carries only its own commit; it currently diffs 32,040 authored lines.
- A sideways two-finger pinch whose second finger lands off the first finger's row (on another swipe row, or off the list) no longer zooms the page and swipes the row instead, where the base handed it to the browser.
- The new
platformadaptation condition is outside the closedwhenvocabulary ofspec:AST-012FR2. spec:AST-057asks for physical touch-device evidence for FR5/FR6, and the unusedresolveReleasesays a flick never fires an action, which contradicts FR5.
[Automated review]
| * is everything else. Pair `ios` with `pointer: 'coarse'` for a touch | ||
| * profile, such as touch motion tuned per platform. | ||
| */ | ||
| platform?: 'ios' | 'other'; |
There was a problem hiding this comment.
spec:AST-012 FR2 keeps the when vocabulary closed to width, pointer, contrast and motion and says new environment fields need an explicit addition to it. platform needs that amendment first, or should leave this stack.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [fix] Swipe actions on `Item` and `ListItem` run on the gesture system. A row claims a sideways touch at 8 px, before a browser commits to scrolling it. On iOS its swipe begins at UIKit's 25 px, from 0, so a short wobble no longer moves the row; on Android and any other touchscreen the row still moves from the touch-down. The pan is published as `Item.swipe`. A second finger before the claim leaves the touch to the browser's pinch, and after it is ignored. The click a browser synthesizes after a swipe is cancelled at its source instead of being swallowed by a 400 ms timer. The row's motion and where a release lands are unchanged. |
There was a problem hiding this comment.
"The pan is published as Item.swipe" promises a handle no app can reach: name is a debugging label, the recognizer never leaves the hook, and requireToFail takes an instance.
291b98e to
11e7d0c
Compare
|
Thanks for the review. Where each point stands on the new head:
|
There was a problem hiding this comment.
This pull request is on hold for an engineering owner's decision: it adds the draft spec:AST-094 and new component:Item requirements (FR9–FR13, AR3–AR5, ORD2–ORD3, PR2, DEC-3, DEC-4), and it calls the 8 px / 25 px swipe split pending owner review. An engineering owner, including the author if they are one, can record approval by commenting /approve-spec <full head SHA> on this pull request, or say which of these deltas must change or land separately. Whatever that decision, these changes are still needed:
- Land the predecessor pull requests (or retarget the base) so this one carries only its own commit; it currently diffs 32,040 authored lines.
- The compact-touch query uses 744 px, while
spec:AST-012FR9 onmaindefines compact as below themdpoint (768 px by default) or under 500 px tall, and theplatformadaptation condition is outside FR2's closed vocabulary. spec:AST-057asks for physical touch-device evidence for FR5/FR6, and the unusedresolveReleasesays a flick never fires an action, which contradicts FR5.- The page does zoom on an off-row pinch, but outside iOS the rows under the fingers slide up to 15 px first; failing the one-finger pan whenever another finger is down would keep them still.
[Automated review]
| export const TOUCH_QUERY = '(pointer: coarse)'; | ||
|
|
||
| /** The viewport is compact: layout behaviours. */ | ||
| export const COMPACT_QUERY = '(width < 744px), (height < 500px)'; |
There was a problem hiding this comment.
spec:AST-012 FR9 (approved on main after this branch point) defines compact as a viewport width below the effective md point (768 px by default) or a height below 500, and says every resolver, including this one, uses that one definition with no size numbers of its own. With 744 px a coarse-pointer screen 744–767 px wide now gets the popover instead of the sheet (DropdownMenu's adaptive story at 760 × 1000: sheet on the base, popover here).
| } | ||
| const target = touch.target instanceof Node ? touch.target : event.target; | ||
| const {recognizers, consumer} = this.participantsAt(target, 'touch'); | ||
| if (recognizers.length === 0 && consumer == null) { |
There was a problem hiding this comment.
Rechecked with real Chromium touch on this head: the page does zoom when the second finger lands on another row or off the list (scale 3.14–5), so the earlier note that the zoom is lost does not hold. Outside iOS the row's one-finger pan still never learns of that finger, claims at 8 px, and slides the row 14–15 px before the browser's pinch takes the touch; base rows stay at 0 px. Failing a possible touch-only one-finger pan while TouchEvent.touches holds another finger would keep them still.
|
Posted by Cindy's agent on her behalf. Parts of this PR re-implement behavior that already exists, or is being specified, as a shared part of core. Converging keeps one implementation per behavior:
This is about where the behavior lives, not about the PR's intent. |
|
Agreed: one implementation.
|
11e7d0c to
d738188
Compare
…d on the restacked head (no emulation; a second finger now gives the swipe up, meta#8336), Android 15 emulator takes (Chrome 124, 540x1200)
github-actions
Bot
added
the
needs:design-review
…llowance under every primary pointer The useMenuPress record's FR9 puts the trigger's held finger under spec:AST-094 FR29 under every primary pointer (FR43), so a finger on a touchscreen laptop may drift 13 pt before the open, as on a phone. The trigger read (pointer: coarse) as its press started and took the long press's 10 px where the pointer was fine. Three cases fail until it does not: a 12 pt drift opens under a fine pointer too, a (12, 12) settle opens there, and nothing reads a pointer query, the trigger's press included.
…lowance under every primary pointer The useMenuPress record's FR9 governs the trigger's held finger by spec:AST-094 FR29 under every primary pointer (FR43). The trigger now hands the long press FR29's 13 px drift allowance whatever the primary pointer, so it no longer reads (pointer: coarse) as its press starts, and the menus drop their coarsePointer import. ContextMenu keeps the long press's own allowable movement. The changeset says the same.
Strict ESLint reported six unused bindings in files this pull request carries: the host's HAPTIC_SWITCH_ATTRIBUTE import, two unused imports in the pan's tests (scrollProbe, ScreenEdgePanGestureRecognizer), the swipe test's drift, the presented-hit-testing test's gestures, and a GestureHost test's before, which now asserts what it was read for: a second finger's moves leave the pan where it was.
…eal angular speed The release velocity of a rotation whose listener sets rotation = 0 on each change, at 2 degrees every 16 ms, read 4.363 rad/s against the 2.182 rad/s of the same stream without a re-base: the test asserted only more than 1.5. It now asserts the 2.18 rad/s (spec:AST-100 FR2), and fails.
The rotation's velocity tracker samples the raw unwrapped angle, which setting rotation does not move, so the setter's shift of the samples read each re-base as extra turn and doubled the release velocity of a listener that re-bases on every change. The setter no longer touches the tracker.
…mates while it runs The proof read the element's animations 230 ms in, after the dip had ended, and asserted only that every animated key is opacity, which an empty list passes: with the cross-fade removed from the plan (the move still landing), the proof still passed. It now reads the keyframe keys right after the call starts and asserts they include opacity and nothing else; the same mutant fails it. Chromium and WebKit pass. (F1's in-flight read from c648034.)
…roller, and its claimed moves are cancelled under pointer events Two comparisons stop at the shadow boundary, each failing a case: - once the host's listener on a recognizer's inner node has seen the finger, isFingerDownIn reads it as outside a light-DOM scroller around that root, so a scroll under it is not the finger's (FR20); - under inputMode 'pointer-events', a claimed pan on a shadow host cancels none of its finger's moves over the inner content, since the finger's target is the inner node and its touches reach the host retargeted (FR19).
…the flat tree isFingerDownIn and the pointer-events finger match compare with containsAlongFlatTree, as the scroll watch already does: a finger on content inside an open shadow root is down in the scroller around that root, and its touches, retargeted to the shadow host, match its pointer finger, so a claimed pan cancels its moves there (spec:AST-094 FR19, FR20).
…achments asks, and only then The host let the last attachment decide whether an element is an action group (useGestureRecognizer always passes the option), and never recomputed it at a detach: a plain attachment after the group's turned the group off, and a group's attachment released left a recognizer that never asked taking presses under a fine pointer. Fails until the host counts the attachments that ask.
…ents asks The host counts the attachments that pass actionGroup: true and keeps the element a group while one remains, recomputed at each detach. An attachment that passes false, as useGestureRecognizer does by default, no longer turns a group off, and a group's last asking attachment taking its leave ends the group.
… that content The presented hit test takes the document's elementFromPoint, which answers a shadow host for anything inside its open root, and compares with Node.contains, which stops at the boundary: a recognizer on a control inside a moving sheet's shadow root gets no finger, and the tap's click goes to the host. Fails until the hit test descends into open roots and compares along the flat tree.
Where a moving element is drawn away from its layout box, the host hit-tests what is drawn under the finger with the document's elementFromPoint, which answers a shadow host for anything inside its open root. The hit test now descends through each open root's own elementFromPoint and compares with the movers along the flat tree, so a recognizer on a control inside a moving sheet's shadow root gets its finger and the tap clicks that control.
…nt lets go The host's touch-action rules sit in an adopted sheet or a style element per document or shadow root, and were never removed, so a page whose last recognizer detached kept them, against spec:AST-094 FR24 (nothing touch-related remains after the last instance unmounts). Fails until a root's rules go with its last marked element.
…th its last marked element The touch-action writer records which elements it marked in each document or shadow root, and when the last one is unmarked (its last recognizer detached) it removes that root's adopted sheet or style element, so nothing touch-related remains after the last instance unmounts (spec:AST-094 FR24). A later mark writes the rules again; an element marked in another root first lets go of the old one.
… the inline style it reads - The motion registry, the host's engine gate and the README name the presented hit test as an engine workaround (spec:AST-013 FR6) with its review condition (re-measure on each iOS release; remove it once iOS WebKit hit-tests a compositor-moved element where it is drawn) and its regression fixture. - While a curve runs the animator holds the value it starts from inline, so presentation.ts and the README no longer say the inline style holds the end.
…core/internal/touch Core ships the internal entry @astryxdesign/core/internal/touch, which re-exports the gesture primitives for Astryx's own packages, and the Lab-import guard fails a Lab import of core outside core's exports (architecture:react-component-runtime INV13). The README and the barrel's header named internal workspace imports and said nothing here is exported; they now name that entry.
…ill needs the element, and the listeners that cancel The release note, the stream's header, the host's comment and the README said the stream is one passive listener per event type and that a document-capture stopPropagation no longer starves the recognizers. Such a stop never hid a listener on the same node, and some subscriptions cancel. They now say what changed: an app's window-capture stopPropagation, or a document-capture stopImmediatePropagation registered before core, no longer hides a touch; a recognizer that must claim still needs the touch to reach its element; the gesture host's touchend, click and contextmenu cancel while a claimer is attached and the page hold's touchmove while it holds; and the stream stays ahead of an app's window-capture listener only until a type's listener is re-added. The README's list of blocking touchmove listeners gains the claimed touch's target and the document while a claiming element moves.
…default it moves
The {stylexOptions} form of astryxStylex now passes StyleX
treeshakeCompensation: true unless the caller sets it. spec:AST-017 FR3
asks the release note to name the old and new default and the option
that restores the old one; it now does.
…er and for the two stops the input stream fixes - A still finger with sub-pixel jitter over a scroll view keeps its tap and scrolls nothing (spec:AST-094 FR18–FR22). - A tap is still recognized under an app's window-capture stopPropagation, and under a document-capture stopImmediatePropagation registered before core's: the recognizers hear touches on the window's capture phase. Chromium and WebKit pass.
…s once Where nothing that claims is attached, the host's touchend listener is passive and cannot cancel the engine's own click after a retargeted tap clicks what is drawn. The shared click guard swallows that late click whatever is attached; this case pins it, as asked on meta#8293.
…esture host's subscriptions The gesture host subscribes no click: the one cancelling click subscriber is the click guard's, added at a window's first arm and kept. The release note, the stream's header and the gestures README listed click with the host's touchend and contextmenu; they now name the guard's own.
There was a problem hiding this comment.
This pull request is on hold for engineering-owner spec decisions: the row's pan begins at 8 px while spec:AST-094 FR17 starts a pan at 10 pt, which needs a dated FR2 owner decision, and the unused resolveRelease and its changeset state that a flick never fires an action, which would need spec:AST-057 FR5 updated. An engineering owner records those decisions by commenting /approve-spec <full head SHA> on this pull request and updating the existing spec on main, and the author may do so if they are an engineering owner. Whatever they decide, these changes are still needed:
- Under a fine primary pointer, a mounted swipe row keeps the gesture host's window listeners subscribed while idle, while
spec:AST-094FR24 allows document listeners only during a press. - The gesture host attaches only where the primary pointer is coarse, which
spec:AST-094FR19, FR43 and DEC-21 reject, andItem.test.tsxasserts that gate. - Narrow the compare range to this pull request's own swipe change: with the unmerged stack beneath it, the range carries 29,814 authored lines for a 1,868-line change.
- Add the physical-device check
spec:AST-057requires for FR5 and FR6 (a real iPhone in Safari and a real Android phone in Chrome).
[Automated review]
| * (the last cancelable `touchmove` at 10 px; cancelling every `touchmove` | ||
| * from 8 px keeps the page still for the whole gesture), Oct 23 2026 | ||
| */ | ||
| claim: 8, |
There was a problem hiding this comment.
spec:AST-094 FR17 says "A pan begins at 10 pt of travel on either axis", and FR2 lets an owner decision depart from a measurement only when it names its date and the measurement it departs from. The description calls this value "an owner decision proposed in #8069"; until an engineering owner records it in AST-094, this value is held.
| * it opens and closes it when it closes, from anywhere short of the commit | ||
| * point. A slower one goes by where it is, against `openFraction` of the | ||
| * open width. So a flick opens the row even from a short drag and closes it | ||
| * from anywhere, and a flick never fires an action: only a release past the |
There was a problem hiding this comment.
"A flick never fires an action" contradicts current spec:AST-057 FR5 ("a drag past the commit point or a fling MUST fire the outermost entry"), which the hook still implements (useSwipeAction.ts L509–511). Until an engineering owner approves the amendment proposed in #8097, resolveRelease, the table's note and the uikit-swipe-actions-values changeset wait on it or leave this range.
| // `spec:AST-057` reads each event's pointer: a finger swipes the row on | ||
| // every device and a mouse never does, so the host's fine-pointer gate | ||
| // (`spec:AST-094` FR19) does not apply to it. | ||
| {perEventPointer: true}, |
There was a problem hiding this comment.
Under a fine primary pointer this opt-out makes the host subscribe its 13 window listeners (pointermove, a capturing scroll, non-passive touchend and contextmenu, and the rest) for as long as a swipe row is mounted (GestureHost.ts isActive(), shouldListen(), install()). Current spec:AST-094 FR24 says "Under a fine pointer a component that uses a gesture listens only on its own element and adds document listeners only during a press, removing them at the release (FR43)", and FR19 on main has no fine-pointer gate left to opt out of. Serving this recognizer the way the host serves an action group, one passive pointerdown on the element and page listeners only while the press is held, would meet FR24.
| // Not opted out of the gate: inactive where the primary pointer is fine. | ||
| expect(taps).not.toContain('ended'); | ||
| // The row swipes under a finger beside it. | ||
| dragLeading(row, 45); | ||
| await settled(); | ||
| expect(xOf(row)).toBe(72); | ||
| expect(warn).toHaveBeenCalledTimes(1); | ||
| expect(warn).toHaveBeenCalledWith( | ||
| expect.stringContaining('attached where the primary pointer is fine'), | ||
| ); |
There was a problem hiding this comment.
This pins a fine-pointer gate that main has replaced: spec:AST-094 FR19 now says "Recognizers attach for every pointer, with FR43's exceptions", and DEC-21 records "Rejected: keeping gestures and press tracking touch-only". Once the host conforms, this case should expect the neighbouring tap to recognize under a fine pointer, with no warning.
| * ONLY WHERE THE PRIMARY POINTER IS COARSE | ||
| * | ||
| * - Recognizers attach, and the host registers listeners, only while the | ||
| * primary pointer is coarse (`spec:AST-094` FR19, FR24; coarsePointer.ts). |
There was a problem hiding this comment.
This is the direction current spec:AST-094 DEC-21 rejects ("Rejected: keeping gestures and press tracking touch-only"): FR19 says "Recognizers attach for every pointer, with FR43's exceptions", and architecture:react-component-runtime INV13 "The gesture host attaches for every pointer, with no touch-only query".
| return tap.numberOfTapsRequired === 1 && tap.numberOfTouchesRequired === 1; | ||
| } | ||
|
|
||
| export class PressTracker implements TouchConsumer { |
There was a problem hiding this comment.
architecture:react-component-runtime INV13 keeps classes to the recognizer family ("its base, the arena, and the host") and fails "a class outside the recognizer family"; the press tracker would be a create… factory. This belongs to the stack beneath this pull request and leaves the range when it is narrowed.
Depends on #8360, #8340 and #8069. Review only this PR's change: vjeux/astryx@item-swipe-gestures-base...uikit/c12-swipe-gestures
Why
On a swipe-action row (
Item,ListItem), a finger drifting 10 px sideways slid the row (UIKit waits for 25 pt), a tap right after a swipe could be swallowed by a 400 ms timer, and an open row left its hidden side's buttons in the tab order and the accessibility tree.What led to it
Part of a series bringing Astryx's touch interactions to parity with native iOS (UIKit). The row hand-rolled its gesture code (an axis lock, a pinch watcher, a touch listener, pointer capture, a click timer), each piece re-implementing Astryx's gesture system (
spec:AST-094) differently, none at UIKit's thresholds.Options and tradeoffs
The 8 px claim with a 25 px start is an owner decision proposed in #8069.
Why this choice
Option 2 fixes all three defects the way every touch component gets them (
spec:AST-094FR10, FR17, FR21).How to check it
On a phone, or in Chrome's device toolbar with touch, open the Item story "Swipe Actions":
We ran every step with real touch in Chromium and the main paths on the iOS 26.2 simulator and the Android 15 emulator; each behaved as listed (recordings below). The unit tests (
pnpm exec vitest run packages/core/src/Item) and the Chromium touch specs pass.Evidence
The story keeps main's 237 elements. Known red until #8671 merges: its touch-bundle check, which a gesture-using
Itemfails by design.Scope