Repository navigation
feat(NumberInput): a held stepper keeps stepping on a steady ramp and commits once, at the release - #8205
feat(NumberInput): a held stepper keeps stepping on a steady ramp and commits once, at the release#8205vjeux wants to merge 1947 commits into
Conversation
|
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
bd65b4e to
c76f574
Compare
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewModified ComponentsCheckboxInput (@astryxdesign/core) · View in Storybook
Item (@astryxdesign/core) · View in Storybook
NumberInput (@astryxdesign/core) · View in Storybook
TreeList (@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/NumberInput | +20.3KB |
+44B |
| core/Pagination | +20.6KB |
+407B |
| core/PowerSearch | +20.7KB |
+416B |
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 | 35.2KB | +685B |
Accessibility Audit
Status: 4 accessibility violation(s) found — 4 serious.
Checkbox pattern - 1 issue(s)
- 🟠 serious: Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds
- Rule:
color-contrast· Affects 1/25 stories · Learn more - WCAG: 1.4.3 (Level AA)
- Rule:
CheckboxList - 1 issue(s)
- 🟠 serious: Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds
- Rule:
color-contrast· Affects 3/19 stories · Learn more - WCAG: 1.4.3 (Level AA)
- Rule:
Radio group pattern - 1 issue(s)
- 🟠 serious: Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds
- Rule:
color-contrast· Affects 3/11 stories · Learn more - WCAG: 1.4.3 (Level AA)
- Rule:
RadioList - 1 issue(s)
- 🟠 serious: Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds
- Rule:
color-contrast· Affects 3/14 stories · Learn more - WCAG: 1.4.3 (Level AA)
- Rule:
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
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved, and it needs changes either way. The stepper hold and a held stepper calling onChange on every step rest only on the draft spec:AST-094 (FR1, FR2, FR11, FR16, FR20 and FR21); an engineering owner records approval of those claims by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Independently, please:
- land the stacked predecessors first (or rebase onto them) so this pull request carries only its own 1,721-line commit instead of 26,788 lines;
- attach the stepper column's press tracker whenever that node is created or replaced, because steppers shown after mount never get the hold;
- stop the stepper's click guard from dropping a
detail === 0activation after a touch press that ended without a click.
[Automated review]
| if ( | ||
| (pointerType === 'touch' || pointerType === 'pen') && | ||
| stepperTrackedPressRef.current | ||
| ) { | ||
| stepperTrackedPressRef.current = false; | ||
| return; | ||
| } |
There was a problem hiding this comment.
Both refs are set at touch-down and cleared only here, by a click. A hold in Chromium, a slide off the column or a scroll ends with no click, so the next click with detail === 0 and no pointerdown (a programmatic click(), or assistive technology that sends no pointer events) is dropped: in Chromium touch emulation click() after a 1.6 s hold left the value at 5, where the base steps 2 to 3. Checking event.detail > 0 here, and clearing both refs at the lift or cancel when no click is owed, keeps those activations.
There was a problem hiding this comment.
Fixed in a76cd60. The guard skips only a click a pointer produced (detail > 0) and clears its flag at every click and when a touch is cancelled. A lift outside keeps the flag, because iOS Safari still sends the button its click after a short slide off. Tests that fail on the previous head: jsdom a click with no pointer after a touch that ended without one still steps and Chromium after a scroll takes the touch, a click with no pointer still steps. A guard against over-clearing: the click an engine sends after a lift outside adds nothing.
| detach(); | ||
| tracker.dispose(); | ||
| }; | ||
| }, [ref, tracker]); |
There was a problem hiding this comment.
Keyed [ref, tracker], this attaches only the node that is in the ref at mount. NumberInput's stepper column renders under hasNumberSteppers, so a column that appears later, or is removed and re-created, is never attached (a 1.2 s hold makes no step and no paint in a jsdom probe), and the removed node stays registered. A callback ref, or a child component that owns the column and calls usePressTracker, would follow node replacement.
There was a problem hiding this comment.
Fixed in a76cd60: a StepperColumn child owns the column and calls usePressTracker, so each column the field mounts gets its own tracker on its own node. Keying a new ref object per node in NumberInput can't work with this hook today, because its getBounds closure keeps the first ref object, so a node-level fix in the hook is the better long-term home (it is open separately). Tests that fail on the previous head: steppers turned on after mount follow a finger and steppers removed and shown again follow a finger, once.
c76f574 to
9159dba
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner's decision on the draft spec:AST-094 (FR1, FR2, FR11, FR16, FR20 and FR21, including the stepper's 0 pt tracking margin against FR11's 70 pt) and on whether a held stepper should call onChange on every step; an engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Independently of that decision, these need changes:
usePressTrackerattaches only to the stepper column present at mount, so steppers turned on later never follow a finger (useGestureRecognizer.ts:127-140).- After a touch press that ends without a click, the next
detail === 0activation is dropped (NumberInput.tsx:937-943), which the draft's own FR21 forbids. - Lint fails at
NumberInput.stepperTouch.test.tsx:263, and the branch carries 26,824 changed lines of stacked work; landing #8052 to #8202 first leaves this pull request with the 1,738-line hold.
[Automated review]
9159dba to
2d89560
Compare
vjeux
changed the title
There was a problem hiding this comment.
Approval waits on an engineering owner's decision on the draft spec:AST-094 for NumberInput's touch stepper hold (FR1, FR2, FR11, FR13, FR16, FR20 and FR21, including the stepper's 0 pt tracking margin and its iOS-only gate), on whether a held stepper calls onChange on every step, and on whether FR4 stands beside the theme motion roles this branch carries; an engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Independently of that decision, these need changes:
usePressTrackerattaches only to the stepper column present at mount, so steppers shown later never follow a finger (useGestureRecognizer.ts:131-144).- After a touch press that ends without a click, the next
detail === 0activation is dropped (NumberInput.tsx:935-941), which the draft's own FR21 forbids. - Lint fails at
NumberInput.stepperTouch.test.tsx:291, three changesets say no component uses modules NumberInput now uses, and the branch carries 31,025 authored lines of stacked work; landing the predecessors first leaves this pull request with the 2,027-line hold.
[Automated review]
| const {onChange, increment} = setup({initial: 8, max: 10}); | ||
| const id = fingerDown(increment, INCREMENT); | ||
| wait(2600); | ||
| expect(onChange.mock.calls.map(([value]) => value)).toEqual([9, 10]); |
There was a problem hiding this comment.
CI's lint job fails here: @typescript-eslint/promise-function-async reads ([value]) => value as possibly returning a promise because mock.calls is untyped. Typing the parameter (or the mock) clears it.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [chore] Internal: the gesture system's DOM host (claims, click suppression, the browser's takeover, the pointer behind a contact). Not exported from the package entry point; no component uses it yet. |
There was a problem hiding this comment.
"no component uses it yet" no longer holds: NumberInput attaches the host through usePressTracker, and touch-experimental-subpaths.md in the same release exports the press tracker publicly. gesture-press-tracking.md and uikit-constants-table.md say the same; release readers get both statements.
2d89560 to
a76cd60
Compare
|
Two notes on the reviews above. Lint: the strict |
There was a problem hiding this comment.
Approval waits on an engineering owner's decision on the draft spec:AST-094 for NumberInput's touch stepper hold (FR1, FR2, FR11, FR13, FR16, FR20 and FR21, including the stepper's 0 pt tracking margin and its iOS-only gate), on whether a held stepper calls onChange on every step, and on whether FR4 stands beside the theme motion roles this branch carries; an engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. The two input-loss issues from the previous revision are fixed and tested, and these still need changes whatever that decision is:
- NumberInput's import grows by about 18.9 KB gzip of touch-only gesture code (
NumberInput.tsx:57-68), whicharchitecture:component-style-authoringINV6 asks to load lazily or justify. - The touch resolver keeps its own
(width < 744px)/(height < 500px)numbers (touchPresentation.ts:75-79), wherespec:AST-012FR9 requires the theme's compact definition (width below the effectivemdpoint, 768 by default). StepperColumnsits between NumberInput's doc comment andexport function NumberInput, so the exported component loses its JSDoc (NumberInput.tsx:541-557).- Three changesets still say no component uses the gesture host, press tracking or the UIKit table, and the hold changeset leaves out the 50 ms phase.
- The branch carries 31,196 authored lines of stacked work; landing the predecessors first leaves this pull request with the 2,199-line hold.
[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.
These are the resolver's own compact numbers. The current spec:AST-012 FR9 defines compact as width below the theme's effective md point (768 by default) or height below 500, and says the web touch presentation resolver and Selector's adaptive presentation keep no size numbers of their own. With 744 here, a coarse-pointer viewport 744–767 px wide (an iPad mini in portrait) gets the popover where the shared definition gives it the sheet. Deriving the width from the theme's md point (the compact definition main now exports) would conform.
There was a problem hiding this comment.
The resolver belongs to the base (#8062, folded into #8076). At #8076 a71f4e5, which this PR now stacks on, its hook reads compact from the theme's md point, and the 744 is gone; the static media constant stays the default, which is the resolver's own question. NumberInput keys on the coarse pointer alone and reads no compact size.
| type PointerKind, | ||
| type PressTracker, | ||
| type UsePressTrackerOptions, | ||
| } from '../gestures'; |
There was a problem hiding this comment.
These static imports put the gesture host, arena, recognizers and UIKit tables into NumberInput's import for every consumer: an esbuild bundle of NumberInput grows from 34,464 to 53,860 bytes gzip. architecture:component-style-authoring INV6 flags a coarse-pointer-only feature above 2 KB gzip and asks the pull request to load it lazily or justify the cost.
There was a problem hiding this comment.
The size report is in the description now: NumberInput's bundle (esbuild, minified + gzip, React and StyleX external) is 56.2 KB at the base and 76.0 KB with #8205 (478b4f9). About 2 KB of the difference is NumberInput's own touch code (NumberInputTouch.tsx, stepperTracking.ts and the stepper table); the rest is the shared gesture system (the host, arena, press tracker and the gesture table the host reads itself), which every touch control on a page shares. It stays a static import on purpose: a lazy chunk would add a network round trip at the first touch, on exactly the devices that need it, and the touch layer's single import site lets a desktop build drop it. The tables are now imported by name, from their own modules; NumberInput reads the stepper table and one row of the gesture table.
| * <NumberInput label="Price" value={price} onChange={setPrice} min={0} step={0.01} /> | ||
| * ``` | ||
| */ | ||
| /** |
There was a problem hiding this comment.
StepperColumn now sits between NumberInput's doc comment ("A number input component for collecting numeric user input…" with its @example, lines 541-551) and export function NumberInput, so that comment documents the private StepperColumn and the exported component has none in editor hovers or the emitted declarations. Moving StepperColumn above the doc comment, or below NumberInput, keeps it.
There was a problem hiding this comment.
Fixed: StepperColumn is gone (the press tracker hook now attaches to a node that mounts later, so the column needs no component of its own), and the doc comment sits directly on NumberInput again (478b4f9).
| this.steps += 1; | ||
| } | ||
| // Timed from after this step's work, as UIKit re-arms its timer. | ||
| this.arm(this.clock.now() + repeatInterval(this.steps)); |
There was a problem hiding this comment.
This re-arms even when step refused (the field turned disabled or read-only mid-hold), and PressTracker reads isEnabled only when a touch begins, so the timer keeps firing and + stays painted pressed beside aria-disabled until the finger lifts. Cancelling the tracking and clearing the paint when the field becomes disabled during a press would release it (architecture:react-component-runtime INV5).
There was a problem hiding this comment.
Fixed in 478b4f9: when the field turns disabled or read-only during a press, the touch layer lets go of it at once. It cancels the tracking and clears the paint, and nothing tracks or paints again until the next touch. New test: a field turned disabled|read-only mid-hold lets go of the press at once, which fails on the previous head with the half still painted. A step refused at a bound still keeps the clock, so a slide onto the other half carries the cadence, as UIStepper's does.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [feat] NumberInput: on iPhone and iPad, a finger held on a number stepper keeps stepping, as a native iOS stepper does: once after half a second, then every half second, and every tenth of a second after three seconds. A tap steps once, when the finger lifts; sliding onto the other stepper carries the repeat to it, and sliding off the steppers stops it. The pressed stepper lights at once and clears at once. A scroll that starts on a stepper still scrolls and steps nothing. Android and other touch screens keep the tap as before (Material has no stepper), and a mouse click is unchanged. A held finger selects no text on any touch screen: the stepper column leaves that to the gesture system's press tracking instead of styles of its own. |
There was a problem hiding this comment.
The hold also drops to every 50 ms from the twentieth step (stepper.autorepeat.fastIntervalMs), which this line leaves out; release readers would expect a tenth of a second to be the top rate.
There was a problem hiding this comment.
Fixed in 478b4f9: the changeset now names the pen and the top rate (every twentieth of a second from the twentieth step).
Android 15, Chrome 124 (emulator golden v2, recorded at 540 x 1200), on this push's heads (meta#8205 40690a8, meta#8218 7615c44): meta#8205 beside main (a tap steps once at the lift without focusing; a 3.45 s hold steps on UIKit's cadence to 10), and meta#8218 beside meta#8205 (the capsule: - then +, a 1.3 s hold, and a tap on + while Gboard is up). Every take passes the gap gate (no frame gap over 60 ms after the recorder warm-up); every frame reviewed; the bands start below Chrome's address bar.
a76cd60 to
40690a8
Compare
vjeux
changed the title
github-actions
Bot
added
the
needs:design-review
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.
meta#8360 now carries the review fixes of the foundation it holds. The two conflicts are this pull request's own files: - GestureHost.ts: meta#8360 counts the attachments that ask for an action group; here the fine-pointer group listener and the per-event recognizer set are gone (every pointer is served, FR43), so the merge keeps the count and drops those two. - GestureHost.test.ts: both sides added the same assertion to the second-finger case; the merge keeps this side's comment. meta#8360's action-group lifetime case counts a group's own pointerdown under a fine pointer, which this pull request replaces with one passive pointerdown on any element that uses a gesture (its own idle-listener case), so the merge leaves it out.
… attached, in this host's terms meta#8360's action-group lifetime case pins that an element stays a group while any attachment asks and stops with the last. Here every element that uses a gesture is served as a group under a fine pointer, so the same invariant reads as the element's one passive pointerdown: with two gestures attached, detaching either keeps it, and detaching the last removes it. It passes on this head.
meta#8360 carries this pull request's predecessors and the review fixes of the foundation it holds; this pull request's own diff is now its six commits (a second finger fails a one-finger pan wherever fingers come from, and the check reruns once that finger is delivered; a press's selection lock gets what it landed on; a pinch's second finger on another pan claims neither; the wider-band edge pan's real-touch proof; text). Two conflicts: - GestureHost.ts: the selection lock's target takes meta#8360's presented target, which is what the press landed on unless an element under it is moving, so it keeps this pull request's fix and meta#8293's correction. - .changeset/gesture-press-tracking.md: meta#8360's text, which names both writers of the press attribute.
ListItem declares --_hit-border-bottom (the divider's width, 0 on the last row) for the touch hit layer, and List.doc.mjs did not list it, so derivedVarRegistry.test.ts failed: "List has undocumented CSS vars in source: --_hit-border-bottom". It is now in List.doc.mjs theming.vars[] as a private var, and in VARS_WITHOUT_DERIVED_MAPPING with its reason: it is the ::after layer's geometry, which follows --border-width, not a property a theme author sets (as with --_thumbnail-hit-inset and --_input-clear-hit-inset). Red first: "List: all source vars are in doc file" failed on the change before this one; it passes now (122 of 122).
…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.
… lift and the browser's menu, keeps a kept press's finger, and goes when the page hides From the review of this pull request, three cases fail on its head: - an armed press installed the page listeners without the claiming ones, so a claimed finger's touchend stayed passive and the browser's menu opened during a claimed long press (spec:AST-094 FR21); - a kept press got its blocking touchmove during an armed press, but its moves were cancelled only where the primary pointer is coarse, so a held stepper on a touchscreen laptop lost its finger (FR11, DEC-21); - a page hidden mid-press cancelled the press but kept the page's listeners until the next lift anywhere (FR24).
…lift and the browser's menu, keeps a kept press's finger, and goes when the page hides - A finger's or a pen's armed press now brings the claiming listeners (the cancelable touchend and the contextmenu canceller) with the page listeners, as wherever the host installs, so a claimed lift clicks nothing and a claimed hold opens no browser menu (spec:AST-094 FR21). A mouse's press needs neither and adds neither. - A kept press keeps its finger under any pointer: its target blocks and its moves are cancelled once its press is delivered, not only where the primary pointer is coarse (FR11, DEC-21). - A page hidden mid-press releases the armed press as a blur does, so the page's listeners go with the cancelled press (FR24).
…'s selection An action group's press is a long press with no minimum duration, so it claims at the press's pointerdown, before any movement. The drag selection hold then cleared the page's selection, so a plain click on a group's button left its Copy or Cut with nothing to act on. The case fails on this head: the selection is gone after the pointerdown.
…age's selection The drag selection hold cleared the page's selection when any mouse or pen contact was claimed, but an action group's press claims at its pointerdown, before it has moved or selected anything, so a plain click on a group's button left its Copy or Cut with nothing to act on. A claim before any movement now keeps the page's selection: the hold still refuses a new one, and puts the page's back over a selection that appears while it runs. A claim after movement clears what its drag selected, as before (spec:AST-094 FR41). The case before the new one now waits for its hold to end a task after the lift, so no hold outlives that test.
…t every pointer does - GestureHost's header, the gestures README and coarsePointer.ts no longer describe the coarse-only host: a finger or a pen takes the touch-down lock under any primary pointer, a kept press's finger is kept during a fine pointer's press too, and recognizers attach for every pointer while the page listeners last a press (spec:AST-094 FR19, FR24, FR41, FR43). - The fine-pointer selection case asserted the replaced rule and passed only because it read iOS WebKit's inline lock without iOS WebKit: it now asserts the lock a fine pointer's finger and pen take, and that a mouse takes none. - FR41's sentence and its verification row say that a press claimed at its own pointerdown, before it moves, keeps the page's selection, while a drag that moved before its claim loses what it selected.
… name their measured causes The hold proofs that need a tap's click skip in Playwright's WebKit with a reason that blamed this story. Measured against a plain button: that WebKit synthesizes no click after a scripted touch on any element, while its own tap path clicks; these proofs script the touch, so the reason now says that. The steppers cancel a touch's pointerdown, not only its mousedown. Canceling the mousedown alone was tried: iOS Safari, Chromium and WebKit's tap path then all step on the click, but Chrome on Android focuses a held stepper at its long press (focusin about 500 ms in, measured on the emulator), which would blur an editing field. So the cancel stays, and the comments name why; WebKit's Linux build, outside spec:AST-013's support, sends no click after a tap there.
…ion, in the present tense The sentence said a drag that moved before its claim loses the selection it started, but the hold clears the page's selection then, whatever made it; and an unclaimed mouse drag kept "today's" behavior, a phrase that ages. It now says a claim after movement clears the page's selection, a press claimed at its own pointerdown keeps it, and an unclaimed mouse drag keeps its released behavior.
This pull request now sits on meta#8665, so a stack carrying it and meta#8665's other dependants (meta#8676) needs no second GestureHost resolution. Two hunks in GestureHost.ts's pointerdown, both this pull request's: - the second-finger check where fingers come from pointer events stays, followed by meta#8665's rule that a right click, a pen's barrel button or a macOS ctrl-click starts no press; - the check that runs again once the new finger is delivered stays, followed by meta#8665's selection lock call, which no longer takes the window.
…events, as a browser sends them The gesture host now reads a finger from its pointer events once it has seen the pointerdown (meta#8336, through meta#8360). This suite's touch helper sent a move or a lift as a touch event alone, which no browser does, so the two slide tests lost the finger and the touched half's paint stayed on. The helper now sends pointermove or pointerup first, as a browser does; the browser proofs, which use real input, pass unchanged.
…as the repeat arms it Under a loaded machine one WebKit run of "a slide onto the other half carries the paint and the repeat" failed with its third step 68 ms off the schedule. The schedule was timed from touch-down, but the hold starts from the press's delivery and the repeat arms each beat from the moment its step ran (stepperTracking.ts). So a slow touch dispatch, or one late beat, moved every later step, and the proof charged it to each of them. Instrumented over repeated runs at load 83 to 105, WebKit's first step sat up to 38 ms after touch-down plus 500 ms, while every later interval stayed within 17 ms of its beat. Each step is now checked against its own beat: the first 500 ms after the press's first paint, which is written when the hold is armed, and each later one its interval after the step before. The leave-and-return proof's resumed beat is timed from the second step the same way. The slack per step is unchanged.
There was a problem hiding this comment.
Approval waits on an engineering owner’s decision: this head rewrites the current component:NumberInput FR4 (a hold that commits once, at the release, on a 250 ms/0.9 ramp that departs from UIStepper’s measured 500 ms cadence) and FR5 (focus by press kind), adds a mouse and pen hold and a finger tracking area 70 px past the steppers, and adds claimed-drag selection rules to spec:AST-094 FR41. Any engineering owner, the author included, can record that decision by commenting /approve-spec <full head SHA> on this pull request, or say which behaviour must change. These changes are needed either way:
- Check the half actually stepped in
handleColumnClickandpressStepper: a mouse click on anaria-disabledstepper now commits a typed draft at the bound (NumberInput.tsx:1037-1051). - Make the proposed FR4 name the finger’s 70 px tracking area, since it says moving off the stepper pauses the repeat.
- Land or split the predecessor pull requests so this diff carries only the stepper hold, and attach real iOS Safari and Android Chrome runs.
[Automated review]
| const click = stepperTouch.takeClick(event.nativeEvent); | ||
| if (click === 'increment' || click === 'decrement') { | ||
| stepValue(click === 'increment' ? 1 : -1); | ||
| } |
There was a problem hiding this comment.
Under a fine pointer every mouse and pen press is captured on the column (NumberInputTouch.tsx:408-411), so its click lands here, and this steps the lift’s half with no check that it can move (stepValue returns early only for a disabled or read-only field). At a bound stepValue still drops the draft and calls onChange when the draft differs from value: with value 5, max 10 and a typed 10, a click on the aria-disabled + commits 10, against current component:NumberInput FR4 (“a stepper that cannot move does nothing”). pressStepper checks the clicked half but steps the lift’s half (:1018-1029). Checking the half actually stepped in both handlers, with a test that clicks an aria-disabled half, would close it.
| | FR1 | The input is a native text input with `role="spinbutton"`, `inputMode` `numeric` when integer-only and `decimal` otherwise, `aria-valuemin` and `aria-valuemax` from the range, `aria-valuenow` from the committed `value`, and `aria-valuetext` set to the formatted value when `formatValue` is supplied. | Current tests | | ||
| | FR2 | Typing changes only a draft; `onChange` is not called while typing. A draft is valid when it parses for the active locale (grouping, decimal separator, digit script, and sign) and, for validity display, lies within the range and meets integer-only. An invalid draft colors the text secondary, sets `aria-invalid`, and fills a persistent assertive region with the localized invalid-number message. | `spec:AST-086` FR3; `architecture:internationalization`; current tests | | ||
| | FR3 | On blur the draft resolves once and ends: an empty draft clears (`onChange(null)` when clearable and a value exists) or reverts; an unparsable or wrong-kind draft reverts; otherwise the number clamps to the range and commits with `onChange(number)` when it differs from `value`. Enter resolves a valid draft the same way and clears an empty draft when clearable. Enter commits nothing for an empty draft without `hasClear`, which stays in the field and is not marked invalid, or for an unparsable or wrong-kind draft, which stays in the field and stays invalid. Enter ends the draft only when its commit clamped. In a field that is not disabled, every Enter outside composition then calls `onEnter`, whatever it committed. | Current tests | | ||
| | FR4 | ArrowUp and ArrowDown without modifiers, the wheel over the focused input (when `isWheelEnabled`), and a stepper press step by one grid position and commit at once. A held stepper repeats once after 0.5 s, then on a ramp whose interval starts at 250 ms and shortens to 0.9 of the last, down to 50 ms; the input shows each step, and the press commits once, at its release. Moving off the stepper pauses the repeat and moving back resumes it with no immediate step; sliding onto the other stepper carries it on; a held press selects no text and opens no callout (`spec:AST-094` FR41). The grid starts at `min` (when it suits integer-only) or 0. From an empty field or an emptied draft, up goes to `min` or 0 and down to `max` or 0. Results round to the finer of the step's and the grid start's precision (at most 12 decimal places), clamp to the range, and never leave integer-only; a stepper that cannot move does nothing, while an arrow or wheel step that cannot move still ends the draft, committing a valid draft's number and dropping an unparsable one. A caller `onKeyDown` that prevents an arrow cancels that step. A wheel step stops the page from scrolling; otherwise the page scrolls. | UIStepper's 0.5 s delay and 50 ms floor, measured on the iOS 26.2 simulator; `spec:AST-094` FR41; current tests | |
There was a problem hiding this comment.
“Moving off the stepper pauses the repeat” holds for a mouse (NumberInputTouch.tsx:364-375), but a finger keeps the press, and keeps stepping, until it is 70 px past the column (NumberInputTouch.tsx:243-248). The record should name both areas, and the 250 ms and 0.9 values need the dated owner decision spec:AST-094 FR2 asks for when a value departs from a measurement.
| * @source GUESS — proposed, pending owner review: UIStepper measured 500 ms between its first repeats (+514, 1017, 1520, 2023, 2525, 3028 ms), iOS 26.2 sim, Oct 23 2026 | ||
| * @measure M-STP20 | ||
| */ | ||
| firstIntervalMs: 250, |
There was a problem hiding this comment.
spec:AST-094 FR1 asks every component to use the measured value, and FR2 lets an owner decision depart from it only when it names its date and the measurement it departs from. Until an engineering owner records that decision, firstIntervalMs and acceleration stay guesses against UIStepper’s measured 500 ms phases.
Depends on #8336, #8173 and #8241. Review only this PR's change: vjeux/astryx@f9728e6...699d690
User need
In a phone browser, holding a NumberInput's + or − does nothing; each step needs its own tap. A native iOS stepper keeps stepping, faster and faster, while held.
What led to it: Astryx's touch-presentation work (
spec:AST-094) matches its components to native iOS controls on phones. Recording UIKit's stepper on the iOS simulator gave its timing, and the owner asked for the same hold with a mouse (item 3).Design and alternatives
onChangeon every step: a parent that clamps or validates the value fights the repeat.onChangefires once, at the release. A held finger selects no text; a drag from a stepper still scrolls.iOS's exact acceleration isn't public, so the fitted ramp (250 ms, each step 10% sooner) and keeping a press alive within 70 px are proposed for owner review. Known gap: each half stays 15 × 14.5 px, under WCAG's 24 px; #8218 makes it 47 × 32 px on phones.
Current specification
spec:AST-094FR1, FR2, FR11, FR16, FR18–FR21, FR24, FR41 as written before FR43 (#8680 follows FR43);component:NumberInputFR4, amended here. Public-API gap (spec:AST-107FR7): the internal press tracker and timing tables.Public delta and caller burden
No API change; the keyboard, the wheel and screen readers are unchanged.
Testing
On a phone, open Storybook's NumberInput "With number steppers" story:
With a mouse, holding + repeats the same way. Unit tests run these rules on a fake clock, and browser tests replay real touches in Chromium and WebKit. Two node checks fail through this stack's bases, not this change: a bundle check that #8671 replaces, and a List row check that #8085 fixes. These local checks are the evidence; no CI run is expected.
Evidence
Recorded on the iOS 26.2 simulator and the Android emulator.
Size (the PR size report's measure, gzip): NumberInput 57.3 → 76.6 KB, CSS +34 B.
Scope
Writing rubric results
R1 narration, R2 research, R4–R6: none in the amended rows. R3 evidence: FR4 cites UIStepper's 0.5 s delay and 50 ms floor, measured on the iOS 26.2 simulator, and current tests.