Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewComponent 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/DateTimeInput | +33.8KB |
+1.3KB |
| core/SegmentedControl | +32.8KB |
+1.3KB |
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 | 35.4KB | 36.5KB | +1.1KB |
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
There was a problem hiding this comment.
Approval waits on an owner decision about the touch direction: holding the selected SegmentedControl segment lifts it, which contradicts design:user-states DR3; touch selection (commit at the lift, drag-to-select, the swallowed click) has no governing spec while the SegmentedControl record is draft; and spec:AST-094 is an unapproved draft. An engineering owner records that decision by commenting /approve-spec c14c96eff25bef007ad09b5d6a2b2ea06b86a760 on this pull request, and the author may do so as an engineering owner.
- A finger tap must still run a
SegmentedControlItemonClickand honour itspreventDefault(), with touch tests for both. - The stacked pull requests should land or be retargeted so this diff is only the SegmentedControl commit.
[Automated review]
| isTouchPresentation && !isDisabled, | ||
| next => { | ||
| if (next !== value) { | ||
| onChange(next); |
There was a problem hiding this comment.
A touch commit lands here directly, so a SegmentedControlItem onClick never runs for a finger tap and its preventDefault() no longer vetoes the selection (the host swallows the touch's click). Routing the commit through the destination item's click path keeps the released order and cancellation; a touch test with an onClick, with and without preventDefault(), would cover it.
| selected, | ||
| ); | ||
| } | ||
| this.committed = value; |
There was a problem hiding this comment.
If a controlled parent declines this value, the lens has already landed on it and committed stays set: the surface jumps back when the motion settles, and a later app-driven change to the same value skips its slide. Sliding back and clearing committed when the value does not come back would avoid both.
c14c96e to
69ea10e
Compare
There was a problem hiding this comment.
Approval waits on a spec-owner decision about SegmentedControl's touch direction: holding the selected segment lifts it, which contradicts design:user-states DR3 (unchanged by this pull request); touch selection (commit at the lift, drag-to-select, the swallowed click) has no governing spec while the SegmentedControl record is draft; and spec:AST-094 is an unapproved draft. An engineering owner records that decision by commenting /approve-spec 69ea10e3e8f500a7a877dcca5efb418bb840b5fd on this pull request, and the author may do so as an engineering owner; DR3 itself still needs its touch amendment. Whatever the decision, these need changes:
- A finger tap must still run a
SegmentedControlItemonClickand honour itspreventDefault(), with touch tests for both. - The stacked pull requests should land or be retargeted so this diff is only the SegmentedControl commit.
- A touch commit the parent declines should slide back instead of landing and then jumping back.
[Automated review]
There was a problem hiding this comment.
Approval waits on a spec decision: the touch presentation lifts the held selected segment, which design:user-states DR3 currently forbids, selects at the end of a touch with no current spec, and rests on the unapproved draft spec:AST-094, so an engineering owner needs to update DR3 for this intentional change and approve or reject the draft's requirements. An engineering owner records that decision by amending DR3 and the SegmentedControl record on main, or by commenting /approve-spec <full head SHA> on this pull request; the author may do so if they are an engineering owner. Independently of that decision, please make touch selection honour SegmentedControlItem's onClick preventDefault() and fire onChange once per tap, split the 28,134 authored lines into the harness, gesture, motion and SegmentedControl pieces, and move the adaptive query change into its own pull request. [Automated review]
09642a2 to
eaaff0b
Compare
eaaff0b to
f4f1a44
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner deciding the touch direction this pull request proposes: the draft spec:AST-094 requirements, SegmentedControl lifting the held selected segment (a departure from the current user-states DR3), themable touch motion with a new platform theme condition, and the two experimental subpaths. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner. Whatever the decision, these need fixing:
- Touch selection calls
onChangeattouchend, so an itemonClickthat callspreventDefault()no longer cancels it, and a declined value firesonChangetwice (useSegmentedTouchTracking.ts,useSegmentedSelectionMotion.ts). - FR7 of the draft spec cites
spec:AST-090, which does not exist. - The
adaptivequery change, the stable segment width and the interaction harness are separate from the touch presentation, and at about 33,500 authored lines the change needs splitting into reviewable pull requests.
[Automated review]
| isTouchPresentation && !isDisabled, | ||
| next => { | ||
| if (next !== value) { | ||
| onChange(next); |
There was a problem hiding this comment.
Under the iOS touch presentation this calls onChange at touchend, before the item's consumer-first onClick (SegmentedControlItem.tsx L248–253) can call preventDefault(), and a drag-selection raises no click, so a consumer veto no longer cancels selection (public-component-api INV7). Commit through the same cancellable path, or skip the commit when the item's click handler prevents default, and add a touch test that vetoes.
There was a problem hiding this comment.
Fixed in cc32269: the lift now commits through the destination segment's own click, so its onClick runs first and preventDefault() keeps the selection, for a tap and a drag alike. The browser's click for that touch is swallowed, so the click path runs once. Interaction tests cover a vetoed tap, a vetoed drag, and onClick running exactly once for each.
| selected, | ||
| ); | ||
| } | ||
| this.committed = value; |
There was a problem hiding this comment.
committed is set before the parent adopts the value. If a controlled parent declines it, the lens stays on the declined segment until settle(), the tap's click calls ctx.onChange a second time, and a later change to that value takes the early return at L486 and skips its slide. Clear committed when the value is not adopted and swallow the click after a gesture commit.
There was a problem hiding this comment.
Fixed in cc32269: a commit that is not adopted (vetoed, or kept by a controlled parent) slides the lens back to the selection and clears committed, so the next change to that value slides. The touch's own click is swallowed, so a declined value gets one onChange. A unit test covers the decline and the later slide; the interaction tests cover the vetoed tap and drag.
| follows. | ||
| - **FR7 — Exits animate as UIKit's do.** A touch presentation MUST play the | ||
| exit its UIKit counterpart plays. **Proposed; pending owner review:** this | ||
| departs from the draft `spec:AST-090` FR1 (exits off by default) and FR10 |
There was a problem hiding this comment.
spec:AST-090 exists neither on main nor at this head, so FR7's departure (and the current-state impact at L234–236) cannot be checked; cite the record that holds FR1 and FR10, or state them here.
There was a problem hiding this comment.
AST-094 comes from #8052, which this branch carries unchanged. The fix belongs in that pull request; this branch picks it up when it restacks.
f4f1a44 to
5c32f68
Compare
|
On the size: this branch is a stack. It is main with merges of the pull requests it depends on (#8094 and its predecessors; #8270 for the gesture host's text-selection lock), each under its own review, and the touch-tracking commits on top. The description's first line names the commits to review here. As the predecessors land, the diff shrinks to those commits alone. The touch-presentation query, the interaction harness and the stable segment width are already their own pull requests (#8062, #8067, #8087). |
There was a problem hiding this comment.
Approval waits on an engineering owner deciding the touch direction this pull request proposes: under a finger on iOS, SegmentedControl lifts the held selection and dims a pressed segment instead of painting the pressed overlay, which departs from the current design:user-states DR3 and DR1, and it rests on the unapproved draft spec:AST-094 together with themable touch motion, a new platform theme condition and two experimental subpaths that have no current authority. An engineering owner records that decision by amending those records on main or by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner. Whatever the decision, these need fixing:
- A finger tap selects an item whose
onClickcallspreventDefault(), and a value the parent declines firesonChangetwice (useSegmentedTouchTracking.ts,useSegmentedSelectionMotion.ts). - Under Reduce Motion the selection scales from 0.88, while
design:reduced-motionallows only an opacity change within 200 ms that no theme can lengthen. - The compact edge is a fixed 744 px, while
spec:AST-012FR9 uses the theme'smdpoint (768 by default). - At 34,428 authored lines the stack should land in its separate pull requests, and draft FR7 cites a
spec:AST-090that does not exist.
[Automated review]
| isPressingRef.current = false; | ||
| const value = motion.release(touch.x); | ||
| if (value != null) { | ||
| onCommit(value); |
There was a problem hiding this comment.
This commits through onChange at touchend, before the item's consumer-first onClick runs, so an item onClick that calls preventDefault() no longer cancels a finger selection (and a drag-release raises no click at all). On this head a tap on such an item called onChange('table') under the iOS gate and nothing on the Android path. Letting the tap's click perform the commit, and giving a drag-release the same cancellation, would keep the released contract; a touch test with a vetoing onClick would cover it.
| selected, | ||
| ); | ||
| } | ||
| this.committed = value; |
There was a problem hiding this comment.
committed is set before the parent adopts the value. When a controlled parent declines it, the tap's click calls ctx.onChange a second time (reproduced: table,table for one tap), the lens lands on the declined segment and jumps back at settle(), and a later programmatic change to that value takes the touch-commit branch at L570–588 and skips its slide. Swallowing the tap's click after the lift commits, and clearing committed and sliding back when the value does not come back, would avoid all three.
| this.animator.play( | ||
| { | ||
| opacity: timedCurve(0, 1, fadeMs, curve), | ||
| scaleX: timedCurve(from, 1, fadeMs, curve), |
There was a problem hiding this comment.
Under Reduce Motion this scales the lens from 0.88 to 1 (sampled at 0.929 after 67 ms) on a clock a theme can lengthen through segmentedControl.reducedMotion.fadeMs. design:reduced-motion on main allows only an opacity change of 200 ms or less under a coarse pointer (DR1, DR2) and no theme value that lengthens it (DR4), so the substitution should fade opacity alone.
| 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 and architecture:public-component-api INV17 on main define compact as width below the theme's effective md point (768 by default) or height below 500, with no numbers of a component's own. With 744 px here, a coarse-pointer viewport 744–767 px wide gets the popover where FR9 gives the sheet, and a theme that moves md is ignored; reading the edge from the theme and testing 767/768 would conform.
| follows. | ||
| - **FR7 — Exits animate as UIKit's do.** A touch presentation MUST play the | ||
| exit its UIKit counterpart plays. **Proposed; pending owner review:** this | ||
| departs from the draft `spec:AST-090` FR1 (exits off by default) and FR10 |
There was a problem hiding this comment.
spec:AST-090 exists neither on main nor at this head, so the departure FR7 asks an owner to approve (and the current-state impact at L235) cannot be checked; cite the record that holds those FR1 and FR10, or state them here.
bcc34c7 to
cc32269
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner deciding the touch direction this pull request proposes: under a finger on iOS, SegmentedControl lifts the held selection and dims a pressed segment instead of painting the pressed overlay, which departs from the current design:user-states DR3 and DR1, and it rests on the unapproved draft spec:AST-094 together with themable touch motion, a new platform theme condition and two experimental subpaths that have no current authority. An engineering owner records that decision by amending those records on main or by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner. The onClick veto and the double onChange are fixed on this head; whatever the decision, these still need fixing:
- Under Reduce Motion the selection scales from 0.88, while
design:reduced-motionallows only an opacity change within 200 ms that no theme can lengthen. - A parent that adopts the value after one frame, such as URL or server state, sees the lens turn back before it slides to the new segment.
- The compact edge is a fixed 744 px, while
spec:AST-012FR9 uses the theme'smdpoint (768 by default), whichmainnow exports. - At 34,655 authored lines the stack should land in its separate pull requests, and draft FR7 cites a
spec:AST-090that does not exist.
[Automated review]
| this.animator.set({x: 0, scaleX: from, scaleY: from, opacity: 0}); | ||
| this.track( | ||
| this.animator.play( | ||
| { | ||
| opacity: timedCurve(0, 1, fadeMs, curve), | ||
| scaleX: timedCurve(from, 1, fadeMs, curve), | ||
| scaleY: timedCurve(from, 1, fadeMs, curve), | ||
| }, | ||
| // This is the Reduce Motion substitution itself: play it as given. | ||
| {reducedMotion: 'keep'}, |
There was a problem hiding this comment.
Under Reduce Motion this scales the lens from 0.88 to 1 while it fades in (sampled on this head: 0.88, 0.929, 0.985, 1 over about 180 ms), and every reduced-motion path goes through it. design:reduced-motion on main forbids scaling (DR1) and allows only an opacity change of 200 ms or less on a touch screen (DR2), with no theme value that lengthens it (DR4), so the substitution should fade opacity alone on a fixed clock.
| requestAnimationFrame(() => { | ||
| if (segment.getAttribute('aria-checked') !== 'true') { | ||
| motion.decline(track, value); | ||
| } | ||
| }); |
There was a problem hiding this comment.
One frame is too short to tell a refusal from a parent that adopts the value asynchronously (router or server state, a transition). With a parent that adopts 200 ms after onChange, the lens heads for Table, turns back toward Grid, and only then slides to Table. Declining at once only when the dispatched click was cancelled (dispatchEvent on a cancelable click returns false), and otherwise waiting for the next value change or a longer window, would avoid the bounce.
| 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 and architecture:public-component-api INV17 on main define compact as width below the theme's effective md point (768 by default) or height below 500, with no numbers of a component's own, and main now exports that definition (compactDefinition). With 744 px here, a coarse-pointer viewport 744–767 px wide gets the popover where FR9 gives the sheet, and a theme that moves md is ignored.
|
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. |
# Conflicts: # internal/interaction-harness/README.md # internal/interaction-harness/src/busy.test.ts # internal/interaction-harness/src/busy.ts # internal/interaction-harness/src/frames.ts # internal/interaction-harness/src/harness.interaction.browser.spec.ts # packages/core/src/utils/pressFeedback.ts
meta#8076's new head carries main 70ea859 with meta#8073's writer of the press attribute on main's press controller, and its README names both writers. utils/pressFeedback.ts keeps that controller with this line's own changes on it: the pointer, drag, scroll and visibility listeners through the shared input stream (meta#8356) and touchcancel only while the primary pointer is coarse (meta#8270); the key path stays at the window's bubble phase, so a Space press the page cancels paints nothing. usePressTracker stays in its own module, one tracker for a component's life (meta#8315), so meta#8073's rebuilt-tracker hook and its test are not taken. The harness files are meta#8076's.
…s, and the action-group tracker writes its own The header and writePress called it the one writer of the press attribute, but main's action-group tracker writes its groups' presses itself. They now say what holds, as meta#8076's gestures README does.
…he press attribute The release note said every press painter writes data-astryx-press through one internal writer, but the action-group tracker (hooks/actionGroupTracker.ts) writes its groups' presses itself, as the gestures README and utils/pressFeedback.ts already say. The note now says paintPress writes every press it tracks and the action-group tracker writes its own.
…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.
…er in the page The marker lasts only while the finger is down. In WebKit the test's reads and the touch commands share one channel, so a poll from the test missed it; a MutationObserver records each change with the paint at that moment.
There was a problem hiding this comment.
Approval waits on an engineering owner's decision about SegmentedControl's touch presentation. The current SegmentedControl record on main defines none. The drag's script-click commit departs from spec:AST-094 FR11, where SegmentedControl is the named exception of family:action-groups. The carried copy of the selected surface departs from design:user-states DR3, and the new segmented.selectionSpring row edits the current FR4 table. An engineering owner records the decision by amending those records on main and commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner.
Whatever is decided, these changes are still needed:
- Remove the tap's 300 ms script
click()and its window listeners inuseSegmentedTouchTracking.ts, so that only the browser's click activates a tap (AST-094 FR11). - Make
scripts/touch-support-bundle.test.mjspass in this pull request; "is absent from the root entry" fails at this head. - Justify SegmentedControl's own touch-only JavaScript and CSS cost against
main, asarchitecture:component-style-authoringINV6 requires. - Land the stacked gesture, motion, harness, press-feedback, menu and build layers through their own pull requests, and drop the recognizers and hooks nothing uses (33,668 authored lines today).
[Automated review]
| const timer = view.setTimeout(() => { | ||
| if (isDone) { | ||
| return; | ||
| } | ||
| view.removeEventListener('click', grab, true); | ||
| finish(clickAndReport(segment)); | ||
| swallowLateClick(segment); | ||
| }, BROWSER_CLICK_WAIT_MS); |
There was a problem hiding this comment.
A tap whose browser click never arrives is selected here by segment.click() after 300 ms, and swallowLateClick (L167–190) then keeps four window capture listeners until the next press or key, even after the control unmounts. spec:AST-094 FR11 keeps a control's activation as the browser's click. Dropping the fallback lets the browser's click alone activate a tap.
| function hideSurface(segment: HTMLElement): void { | ||
| if (!ownSurface.has(segment)) { | ||
| ownSurface.set( | ||
| segment, | ||
| HIDDEN_SURFACE.map(([property]) => [ | ||
| property, | ||
| segment.style.getPropertyValue(property), | ||
| segment.style.getPropertyPriority(property), | ||
| ]), | ||
| ); | ||
| } | ||
| for (const [property, value] of HIDDEN_SURFACE) { | ||
| segment.style.setProperty(property, value, 'important'); | ||
| } | ||
| } |
There was a problem hiding this comment.
A drag from the selected segment hides that segment's own surface with inline !important and carries a copy, while design:user-states DR3 keeps the selected item's raised surface unchanged during a hold. This departure waits on an engineering owner's decision.
| | `springs.menuClose` | damping ratio 0.85, response 0.35 s | measured: UIMenu closing, iOS 26.2 simulator, 2026-10-23 | | ||
| | `springs.subMenuOpen` | damping ratio 0.85, response 0.4 s | measured: UIKit's own spring for UIMenu's sub-menu opening, iOS 26.2 simulator, 2026-10-24 | | ||
| | `springs.subMenuBack` | damping ratio 1, response 0.4 s | measured: UIKit's own spring for UIMenu's sub-menu header back, iOS 26.2 simulator, 2026-10-24 | | ||
| | `segmented.selectionSpring` | response 0.4 s, damping ratio 0.85 | measured: UISegmentedControl's selection slide, iOS 26.2 simulator, 2026-10-23 | |
There was a problem hiding this comment.
This adds a SegmentedControl role to the current FR4 table. FR4 and DEC-5 route a component's measured roles through the generated motion role table from the component's own record, and component:SegmentedControl names none. The row needs an engineering owner's exact-head /approve-spec, or the role should join through the component's record.
Depends on #8094. Review only this PR's change: vjeux/astryx@7cecbcc...93c2301
User need
Astryx is making its core components behave like UIKit under a finger (
spec:AST-094). On a phone, dragging across a SegmentedControl does nothing, and holding a segment selects its text. On iOS you slide the selected segment and let go on the one you want.Problem and solution fit
onChangeonce;onClickcan veto); a drag that starts elsewhere chooses where it lifts. Letting go off the control chooses nothing.Current specification
component:SegmentedControlFR3,spec:AST-020FR9 and DEC-5 (a slide-off cancels);spec:AST-094FR11; the named exception offamily:action-groups. Touch rows: the record owner's draft #8596, whose FR10 reads "the lift commits the segment nearest the finger".Public delta and caller burden
No API change and no new theme state. Gaps: no pressed lift until the owner's theme role exists; no UIKit stretch.
Design and alternatives
onChangewould repeat; UIKit commits once); swapping label weights mid-drag (bold labels are wider, so segments would shift).Evidence
Scope
Testing
Automated, passing:
pnpm test:interaction SegmentedControl.interaction(real touch, Chromium and WebKit) also checks the 40%/60% release point, a lift off the control, a back-and-forth on a boundary and right-to-left; unit tests cover the logic. Recorded on the iOS 26.2 simulator and the Android emulator. Known red:touch-support-bundle"is absent from the root entry" (#8671).