Repository navigation
Conversation
Adds internal/interaction-harness (@astryxdesign/interaction-harness) and playwright.interaction.config.ts: phone-sized touch projects in Chromium and WebKit for *.interaction.browser.spec.ts specs. Touch scripts are data (tap, drag with hold and rest, flick with an exact release velocity and velocity profiles, hold-then-drag, pinch, rotate, any path, a second finger mid-gesture), played as real engine input: CDP Input.dispatchTouchEvent with scripted timestamps in Chromium, WebKit's own input command in WebKit. The harness's self-test proves the timestamps, a native fling and multi-touch delivery; a pr-interaction CI job runs the proofs against each PR's Storybook build, and a container script runs the WebKit project where host libraries are missing.
Springs, scroll physics, timing curves, navigation values and gesture thresholds for the touch presentations of core components, each with its source (Apple documentation, a WWDC session, WebKit's UIKit-matched source, or a measurement of UIKit on the iOS 26.2 simulator) or labelled a guess with its measurement task. A test enforces the source rules on every domain file, in their JSDoc and typed forms, and checks the list of simulator measurements still owed.
Pure functions for the touch presentations: a closed-form damped spring with every Apple parameterization and Core Animation's settling duration, a spring chasing a moving target, UIScrollView's coast, rubber band and release projection. Tests hold them to an RK4 integration, WebKit's spring solver, the WWDC conversion equations and values read from UIKit, and play the constants table through them.
…rena An internal gesture system for touch presentations, not exported from the package. GestureRecognizer carries UIKit's states and allowed transitions, discrete and continuous recognizers, require-to-fail, simultaneous recognition on request, shouldBegin and shouldReceiveTouch, cancelsTouchesInView and the touch delays. GestureArena settles each touch sequence without the DOM: participants, resolution order, claims, delivery to the view, click dispositions (allow, suppress, defer and replay) and timers as deadlines on the event clock. Its rules are tested with scripted recognizers, independent of any real one.
…sholds Tap recognizes at the lift within 45 pt of movement, taps 0.35 s and 45 pt apart, and a 1.5 s hold; long press begins at exactly touch-down + 0.5 s on the event clock within 10 pt, even when the main thread was blocked, and a zero duration begins on the touch itself. The arena tests with these real recognizers cover tap against double tap, delegate requirements, deferred clicks and cancellation.
Touch behaviours key on a coarse primary pointer, layout behaviours on a compact viewport, and presentations that need both (a sheet in place of a popover) ask for both. utils/touchPresentation.ts holds the three queries, SSR-safe hooks (useTouchPresentation; useMotionPresentation for components with no interaction to infer from: UIKit motion under a finger, theme tokens under a mouse) and a one-moment read. Styles write the same queries as StyleX media keys, and a test keeps core's compact-touch keys spelled as the shared query. A compact viewport is narrower than 744 px or shorter than 500 px, the closest a size gets to UIKit's compact size class: an iPad mini in portrait keeps the anchored popover and a phone in landscape gets the sheet; a Max-size iPhone in landscape is the known miss. The adaptive popover-or- sheet presentation reads the shared query; its docs, stories and tests follow.
A file that reads only defineConsts values from a .stylex.ts module lost
that import under the legacy {stylexOptions} form Storybook uses: the
babel wrapper's StyleX instance ran without treeshakeCompensation (the
unplugin applies its Vite default only to its own instance, which runs
after the wrapper), so once stylex.create was compiled the TypeScript
transform dropped the import and the defining module never reached the
build. A constant used as a media-query key failed the build with
"Invalid empty selector"; one used as a value shipped as a custom
property nothing declares. The wrapper now gets treeshakeCompensation by
default.
The layer split also substituted constants only within each layer, so a
constant defined on the library side and read on the product side stayed
a placeholder in either form; every layer now sees every constant.
A production build now warns, naming the variable and the rule that reads
it, when the StyleX stylesheet reads a generated custom property nothing
declares; undefinedVariables: 'error' fails the build instead, and this
repo's Storybook and Sandbox configs set it so CI catches the next case.
Pure functions for the touch presentations: a closed-form damped spring with every Apple parameterization and Core Animation's settling duration, a spring chasing a moving target, UIScrollView's coast, rubber band and release projection. Tests hold them to an RK4 integration, WebKit's spring solver, the WWDC conversion equations and values read from UIKit, and play the constants table through them.
createAnimator plays springs and UIScrollView coasts as Web Animations keyframes on translate, rotate, scale and opacity, on one explicit clock, so they keep running while JavaScript is busy. Presentation values and velocities come from the curves, so a finger can catch any animation and a new target keeps the velocity; the end state is committed inline and held by the keyframes through a main-thread block, and a finished animation retires when its own time reaches the curve's end, so a sampler can pause it; Reduce Motion substitutes UIKit's cross-fade.
|
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
… Chromium The Chromium driver sent a lift of one finger of several as a touchMove listing the fingers still down, assuming CDP releases a point a move omits. It does not: the lifted finger stayed down. A touchEnd that lists the lifting fingers releases exactly those while the others keep moving, so the driver sends that, and a self-test lifts one of two fingers and checks the release, the other finger's moves and the touchend's remaining touches. Playwright's WebKit sends that touchend with no remaining touches, which iOS never does. The harness does not work around it: drivers expose partialLifts, and PARTIAL_LIFT_SKIP is the reason a proof cites when it skips; the README lists it with the other engine limits.
Pause every Web Animation, seek it to a time and read the presented transform and opacity, then compare the curve with oracles that share no code with the motion under test: cubic-bezier, the SwiftUI spring (response, dampingFraction, initial velocity), UIScrollView deceleration and UIKit's rubber band. Storyboards photograph seeked animations at t = 0, 16.7, 33.3 ... ms or each step of a scripted touch, and write a PNG contact sheet plus the JSON trace a spec asserts, under the gitignored test-results/interaction-evidence. A timer gate holds a component's own timers while a filmstrip is taken. pnpm storyboards runs the tagged tests.
…sented values An animation that keeps its end value in a run of identical final keyframes (held so a later interruption can read it) reported its whole duration as the curve: storyboards filmed the hold, waitForAnimation's interval reached past the landing, and waitForRest, which also required every animation to leave the running state and read only transform, timed out. The curve now ends where that run starts (HeldAnimation.curveEndMs, waitForAnimation's to, the default storyboard times), and rest is no animation pending or before its curve's end plus the presented transform, translate, rotate, scale and opacity (and ::backdrop opacity) still for 3 frames, whatever the playState. sampleCurve composes translate, rotate and scale with transform, so curves of the individual properties are sampled.
Timestamped composited frames (Chromium's screencast and WebKit's own), a marker the frames can find, and the busy-main-thread proof: block the page's main thread mid-flight and show the element still moving every frame, with a requestAnimationFrame animation that freezes as the negative control. Chromium trace counts of Layout, Paint and style work inside an animation window, and long tasks. The exemplar spec proves the BottomSheet drag to a detent with all of it: the drag follows the finger, a flick dismisses, the settle matches its timing function, keeps advancing through a blocked main thread in Chromium and WebKit, does no Layout or Paint, and gets a drag and settle storyboard.
…ed machine The proof asserted a stall under 40 ms and near-exact frame counts, so a dropped screencast frame or two on a loaded runner failed it, and frames delivered out of order read as the element stepping backwards. busyWindowProof now returns a verdict that tolerates what load does to a screencast and nothing a frozen animation does: a median frame interval of at most 20 ms, no stall longer than three screencast intervals, and at least 90% of the window's whole frame intervals presenting a new position (one miss always allowed), with the raw numbers in a summary. Screencast frames are sorted by presentation time, the cadence comes from the frames around the window, and blockMainThread can block from inside the page in the frame an animation has run, so a short settle is still judged at length on a busy machine. The exemplar judges its settle until it is within 2 px of rest, since the screencast rounds to whole pixels. A unit test covers the limits; the rAF negative control still fails every criterion.
The pan begins past 10 pt on either axis and leaves that travel out of its translation, as UIPanGestureRecognizer does; axis and one-way directions with axisRatio, axis lock, finger changes without jumps, scrollEdge, and an opt-in non-UIKit scrollHandoff. VelocityTracker defaults to UIKit's filter (0.2 x the newest event's velocity + 0.8 x the previous one's), which reproduces every value UIKit reported on recorded streams.
…zers The rest of UIKit's recognizer set on the gesture system: swipe recognized during the motion, pinch measured from the starting span moved by its hysteresis, unwrapped rotation, edge pans resolved against the writing direction that fail at touch-down outside their band, and hover for mice and hovering pens.
The touch-action an element gets from its recognizers (pinch-zoom stays unless a pinch or rotation recognizer is attached), what the scrollers under a touch could still do along the scroll chain, and UIKit's haptic feedback kinds on the web: navigator.vibrate where it exists, the switch tap haptic in iOS Safari.
…s takeover One host per document routes fingers (touch events, paired with their pointer events), mice and pens to the recognizers on the hit path. A recognizer that owns a touch cancels its touchmove through a non-passive listener; pointercancel, an uncancelable move or a scroll mean the browser took the touch; a claimed touch's touchend is cancelled and its click swallowed, a deferred click replayed when its recognizer fails. pointerIdOf names the pointer behind a tracked contact, so a held finger can be handed to code that follows pointers.
… and hooks PressTracker applies UIControl's events and its 70 pt tracking margin, the content-touch delay inside scrollers, the quick-tap flash and the scroll brake, with two profiles: control (UIButton) and cell (a row: delayed highlight everywhere, cancelled past the pan hysteresis, no flash). paintPress is the one writer of data-astryx-press and never clobbers a held row. installPressAttribute paints every marked surface with one tracker per touch, picks the profile from the marker's value and releases on its clock. useGestureRecognizer attaches a recognizer with a stable identity and no render per move.
The same touch scripts run in Chromium (CDP touches with timestamps) and WebKit (its own touch input): touch-action per element, claims over a scroller, no ghost click, scroll edge, pinch on its element only, a second finger, and a long press at exactly 500 ms under a blocked main thread. The README documents the system for component authors.
![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 spec decision. ContextMenu's new touch timeline (growth from 150 ms, commit at 400 ms, menu at 735 ms), the trigger growing while its menu is up, the touch scroll lock and the no-haptic choice for iOS Safari rest only on the draft ContextMenu record and the unapproved spec:AST-094. An engineering owner can record the decision by commenting /approve-spec <full head SHA> on this pull request (the author can do so as an engineering owner), or say which decision should change. Whatever that decision is, these changes are still needed:
- Land the stacked predecessors first, or retarget onto the last of them, so that this diff is the 1,840-line ContextMenu commit rather than 24,862 authored lines.
- Regenerate the
search closeCLI golden, which the new ContextMenu guidance pushes from 44 to 45 matches, so that the requiredtestcheck passes. - Re-attach the press recognizer when the trigger node changes, because a
triggerAsswitch currently leaves it on the detached element (useGestureRecognizer.ts:71-79,ContextMenu.tsx:882). - Move the
setIsTouchOpen(false)andrelease()calls from the Effect atContextMenu.tsx:744-753into the close handlers, and restore the two consumer-handler regression cases from #7167. - Add the
## Writing rubric resultsfor the new AST-094 record to the description.
[Automated review]
| { | ||
| guidance: true, | ||
| description: | ||
| 'Leave a little room around a block trigger: a held finger grows it from its center, by about 6%, until the menu closes.', |
There was a problem hiding this comment.
This guidance ends with "until the menu closes", and the CLI search scores guidance text. The required test check fails here: test-node (1/4) finds 45 matches for astryx search close where packages/cli/test/__golden__/no-icon-set/search-close.json expects 44. Please regenerate that golden, or reword the line.
| useEffect(() => { | ||
| if (wasOpenRef.current && !isOpen) { | ||
| setIsTouchOpen(false); | ||
| pressFeedbackRef.current.release(); | ||
| } | ||
| wasOpenRef.current = isOpen; | ||
| }, [isOpen]); |
There was a problem hiding this comment.
This Effect sets state (setIsTouchOpen(false)) and starts the spring-back in reaction to isOpen, and it synchronizes no external system (react-component-runtime INV2/INV3). The handlers that close the menu can do both calls directly: the layer's onHide and updateOpenState(false). Then the trigger springs back with the close itself, and the extra render goes away.
| useIsomorphicLayoutEffect(() => { | ||
| const element = ref.current; | ||
| if (element == null) { | ||
| return undefined; | ||
| } | ||
| return getGestureHost(element.ownerDocument).attach(element, recognizer, { | ||
| manageStyle, | ||
| }); | ||
| }, [ref, recognizer, manageStyle]); |
There was a problem hiding this comment.
The attach is keyed on the ref object, so it never re-runs when the node behind the ref changes. ContextMenu swaps its trigger between div and span with triggerAs, and after that swap the recognizer, its touch-action and its non-passive listener stay on the detached node, so a held finger opens nothing in iOS Safari. Attaching through a callback ref, or re-running the attach on node change, handles replacement (react-component-runtime INV6).
| expect(document.body.style.position).toBe(''); | ||
| }); | ||
|
|
||
| it('passes touch events through to the consumer’s own handlers', () => { |
There was a problem hiding this comment.
This replaces two #7167 regression cases only in part. Please add a held press with consumer touch handlers that still opens at 735 ms, and an early lift whose consumer onTouchEnd calls preventDefault() and opens nothing (component-test-sufficiency INV3).
|
Two regressions at 265cec4, with a fix offered on top of it (not pushed here): vjeux@9a763f4 (branch
The offered commit keeps today's 500 ms long press armed until the touch layer runs, and makes the trigger a pressable surface only then: the layer's handle carries the marker, so ContextMenu no longer calls Tests in that commit:
Results: unit 2109 pass, pressable coverage green, |
There was a problem hiding this comment.
Approval is on hold until an engineering owner decides two additions that no current spec covers. One is the page scroll lock under a touch-opened ContextMenu popover: spec:AST-094 names a page lock only for modal presentations, and its FR32 wants an outside pan to close an anchored menu. The other is the new public useLongPress stages and start(point, time) API. Any engineering owner can record that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever the decision, these need changes:
- A held finger that lands before the lazily loaded touch layer attaches opens nothing, which is why 14 of the ContextMenu interaction proofs fail in CI.
- The
testcheck fails onpressableCoverage.test.tsand, once merged withmain, on the duration guard for the newpr-interactionjob, which sets no timeout. - Removing the trigger's
user-select: nonelets a mouse select trigger text, a fine-pointer change (spec:AST-017FR59). - Under AST-094 FR33, the touch-opened menu should sit beside the lifted trigger, the lift should follow the recognizer's drift rule, and a sheet presentation should not lift.
- The diff carries about 36,000 authored lines of unmerged predecessors, which should land or be retargeted so this pull request holds only the ContextMenu change.
[Automated review]
| onTouchCancel: handleLongPressTouchCancel, | ||
| } = useLongPress({ | ||
| disabled: isDisabled, | ||
| disabled: isDisabled || touchModes, |
There was a problem hiding this comment.
Under the touch model this turns the 500 ms long press off, but the recognizer only exists once the lazily loaded ContextMenuTouchLayer has rendered and attached. A hold that starts before that opens nothing. In this head's static Storybook, a hold started as the story renders gets no menu, and the same hold after 1.5 s opens it. That matches the 14 ContextMenuLongPress proofs failing in pr-interaction. Keeping this long press on until the layer reports attached would close the gap.
| WebkitTouchCallout: 'none', | ||
| WebkitUserSelect: 'none', | ||
| userSelect: 'none', |
There was a problem hiding this comment.
Removing these from the trigger also removes them outside the touch model. With a mouse, the trigger's computed user-select is now auto, and a drag selects text inside a ContextMenu trigger, which the base prevents. Under presentation="popover" in iOS Safari, the comment above explained they stop the native text and callout UI from competing with the long press. spec:AST-017 FR59 keeps fine-pointer behavior unchanged in touch work, so these should stay on the trigger outside the touch model.
| readPresentation(presentation, {whenOmitted: 'touch', compact}) | ||
| .touchModes, | ||
| ); | ||
| openAtLocalPoint(local.x, local.y, triggerRef.current, 'menu'); |
There was a problem hiding this comment.
This anchors the touch-opened menu at the finger, inside the lifted trigger. In a capture, the menu's top edge sits 74 px above the lifted card's bottom edge, over its corner. spec:AST-094 FR33 asks a held finger's ContextMenu on a block trigger to "lift the trigger above the page and show the menu beside it".
| <Suspense fallback={null}> | ||
| <ContextMenuTouchLayer | ||
| triggerRef={triggerRef} | ||
| isShown={triggerAs !== 'span'} |
There was a problem hiding this comment.
This grows the trigger for every surface, including presentation="bottom-sheet" and adaptive on a compact touch screen, where the card stays at scale 1.062 behind the sheet's scrim. AST-094 FR33 says "a menu presented as a bottom sheet follows the sheet", so the growth should also be off when surface === 'bottom-sheet'.
| <TriggerElement | ||
| ref={useMergedRefs(ref, triggerRef)} | ||
| {...triggerProps} | ||
| {...(touchModes ? pressable : null)} |
There was a problem hiding this comment.
This marks a disabled trigger too. The press controller skips only :disabled and [aria-disabled="true"], so it times the onset, writes data-astryx-press and locks selection on a disabled ContextMenu that has no touch layer to read it (AST-094 FR24). touchModes && !isDisabled ? pressable : null avoids that.
| // The trigger is a pressable surface of core's one press machine | ||
| // (utils/pressFeedback.ts) under the touch model; the touch layer's press | ||
| // feedback follows that machine's pressed state. | ||
| const pressable = usePressFeedback(); |
There was a problem hiding this comment.
Since the growth moved into the touch layer, this file marks the trigger but no longer reads the pressed state. pressableCoverage.test.ts > "marks nothing that does not paint a press" now fails on ContextMenu/ContextMenu.tsx, and that failure is what turns test-ui (2/4) red.
| if (next) { | ||
| start(performance.now()); | ||
| } else { | ||
| fail(performance.now()); |
There was a problem hiding this comment.
The growth springs back when the press machine drops the press, at 10 px of straight-line travel (PRESS_SLOP_PX). The menu's recognizer keeps the press up to 11.5 px on either axis. A finger that drifts (8, 8) px before 735 ms therefore gets the menu over a trigger at rest. Ending the growth on the recognizer's own failed or cancelled would keep the two in step (AST-094 FR1, FR33).
| }, | ||
| ); | ||
|
|
||
| useEffect(() => { |
There was a problem hiding this comment.
This Effect publishes the layer's handle to ContextMenu and names no external system it synchronizes (architecture:react-component-runtime INV3). useImperativeHandle on a ref that ContextMenu passes would expose the same handle without an Effect of its own.
| # them, so a change to an instrument is proven by its negative controls | ||
| # before a component spec relies on it. Chromium only on these runners; | ||
| # see the harness README for running WebKit. | ||
| pr-interaction: |
There was a problem hiding this comment.
On the merge with current main, test-node (4/4) fails main's CI duration guard with "pr-interaction has no pull-request timeout". This job needs a timeout-minutes within the guard's budget.
…s the menu The lazy touch layer (265cec4) left a finger that landed before the layer attached with nothing to open the menu, which is why the pull request's own interaction proofs failed when pressed as the story rendered. - Under a coarse primary pointer the layer starts loading with ContextMenu's module, so it is usually ready before the first finger lands. - Until the layer attaches, a finger keeps today's 500 ms long press, so an early hold still opens the menu. - ContextMenu spreads core's static pressableProps marker instead of calling usePressFeedback itself; the layer installs the press machine. This keeps pressableCoverage.test.ts's rule that a file calling usePressFeedback paints a press. - The trigger keeps main's iOS callout and text selection lock (spec:AST-017 FR59), so a mouse cannot select the trigger's text. Test: a finger held before the layer attaches opens the menu at 500 ms (the layer's module never arrives); it fails without the fallback.
There was a problem hiding this comment.
Approval is on hold until an engineering owner decides two additions that no current spec covers: the page scroll lock under a touch-opened ContextMenu popover (spec:AST-094 names a page lock only for modal presentations, and its FR32 wants an outside pan to close an anchored menu) and the new public useLongPress stages and start(point, time) API. Any engineering owner can provide or identify the governing spec for them, or record approval by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever that decision, these need changes:
- The branch conflicts with
mainin 13 files, sotest,buildandlinthave not run; rebase ontomainand keep its interaction harness andpr-interactionjob. - Under AST-094 FR33 the touch-opened menu should sit beside the lifted trigger, the trigger should not lift behind a bottom sheet, and the lift should not drop when a finger drifts 10 to 11.5 px before the menu opens.
- FR33's handoff (the opening finger picking a row after 10 pt of travel) and FR32's dismissal on an outside pan are missing under the touch model.
- The Effect that publishes the touch layer's handle names no external system (
architecture:react-component-runtimeINV3), a disabled trigger still carries the press marker (FR24), and one changeset still says no component uses the context-menu constants. - The diff carries about 36,600 authored lines of unmerged predecessors, which should land or be retargeted so this pull request holds only the ContextMenu change.
[Automated review]
| // Under the touch model the trigger is a pressable surface of core's | ||
| // one press machine (utils/pressFeedback.ts); the touch layer installs | ||
| // the machine and its press feedback follows the pressed state. | ||
| {...(touchModes ? pressableProps : null)} |
There was a problem hiding this comment.
This marks a disabled trigger too. The shared touch press controller skips only :disabled and [aria-disabled="true"] (utils/pressFeedback.ts:77), so while any other pressable surface keeps it installed it times its onset, writes data-astryx-press and locks selection on a disabled ContextMenu that has no touch layer to read it (spec:AST-094 FR24). touchModes && !isDisabled ? pressableProps : null avoids that.
| '@astryxdesign/cli': patch | ||
| --- | ||
|
|
||
| [chore] The UIKit constants table gains ContextMenu's touch timeline as measured on iOS 26.2: the press feedback starts at 150 ms, the press commits at 400 ms, and the menu displays at 735 ms. It also records the drift tolerance, and the press feedback's growth, spring and display latency. A closed-form press-feedback curve, checked against UIKit's per-frame presentation, comes with them. No component uses them yet. The feedback's spring and display latencies are motion roles a theme can retune, and `astryx docs motion` lists them. The onset, the commit and the menu's moment decide when a press counts and who gets the touch, so they stay out of the theme. |
There was a problem hiding this comment.
"No component uses them yet" no longer holds in this diff: .changeset/contextmenu-touch-timeline.md ships ContextMenu on these constants, so the combined release notes contradict each other. Dropping that sentence, or letting this changeset leave with its predecessor when the stack is split, fixes it.
The harness, ci.yml, ci-test-routing and playwright.interaction.config.ts take facebook#8045's canonical resolution. ContextMenu's doc and test keep this branch's text (it already carries main's compact-touch wording).
One conflict: ContextMenu.test.tsx's imports, resolved to the union.
There was a problem hiding this comment.
Approval is on hold until an engineering owner decides two additions that no current spec covers: the page scroll lock under a touch-opened ContextMenu popover (spec:AST-094 names a page lock only for modal presentations, and its FR32 wants an outside pan to close an anchored menu) and the new public useLongPress stages option and start(point, time) argument. An engineering owner can provide or identify the governing spec for them, or record the decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever that decision, these need changes:
- Land or retarget the predecessor pull requests so this diff holds only the ContextMenu change; it carries about 36,000 authored lines today.
- Under AST-094 FR33, show the touch-opened menu beside the lifted trigger, leave the trigger unlifted under a bottom sheet, and keep the lift when a finger drifts 10 to 11.5 px before the menu opens.
- Add FR33's handoff, so the opening finger picks a row after 10 pt of travel, and FR32's dismissal on an outside pan.
- Reset the velocity tracker after a still pause and drop its alternative strategies (
spec:AST-100FR2), name the external system for the touch layer's handle Effect or drop it, keep the press marker off a disabled trigger (FR24), and correct the changesets that say no component uses this code. - Add real-device iOS Safari and Android Chrome evidence, and explain or fix
ContextMenuItem's import growth from 16.4 KB to 53.4 KB gzip.
[Automated review]
| // where it is; ContextMenu places the anchor under the finger. | ||
| feedbackRef.current.hold(); | ||
| hasPressOpenedRef.current = true; | ||
| onOpenRef.current(press.press ?? press.location()); |
There was a problem hiding this comment.
The menu opens here, but the finger that opened it is never handed to the menu's press model, so under the touch model sliding it onto a row and lifting picks nothing. spec:AST-094 FR33 has that finger pick once it has travelled the handoff distance (FR26–FR28 from then on), and module:DropdownMenu/useMenuPress FR11, now current on main, makes a handed-off pointer the opening press. FR33 also sends a press outside to FR32, which closes the menu as an outside pan begins; ContextMenu still dismisses on an outside mousedown only.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [chore] An internal `usePresentation` / `readPresentation` resolves a component's `presentation` prop into the surface to render and whether its touch input modes apply, keeping an omitted value distinct from an explicit `'popover'` so a caller's choice always wins over a touch default. No component reads it yet; behavior is unchanged. |
There was a problem hiding this comment.
"No component reads it yet; behavior is unchanged" no longer holds in this diff: ContextMenu resolves its presentation with usePresentation (ContextMenu.tsx:359) and .changeset/contextmenu-touch-timeline.md ships that change, so the combined release notes contradict each other. Drop the sentence here, or let this changeset leave with its predecessor when the stack is split.
| '@astryxdesign/cli': patch | ||
| --- | ||
|
|
||
| [feat] Themes can retune touch motion roles. `defineTheme({motion})` takes `springs`, `durations` and `curves` keyed by motion role, the table path of a measured touch motion value (`springs.sheetPresent`, `navigation.transitionMs`), at the root or in an adaptation rule, and writes one `--motion-*` variable per role it sets. A role the theme leaves out keeps its measured default, an unknown role id is refused, and the duration scale (`fast`, `medium`, `ratio`) is optional when a theme sets only roles. No shipped component reads the roles yet. `astryx docs motion` lists every motion role with its CSS variable and default, and the theme authoring guide and template describe the new fields. |
There was a problem hiding this comment.
"No shipped component reads the roles yet" no longer holds in this diff: ContextMenu's press feedback reads its spring and latency roles (contextMenuPressFeedback.ts:149, :178), and the interaction proof "a theme retunes the press feedback (a motion role)" depends on it. Drop the sentence here, or let this changeset leave with its predecessor.
|
vjeux's position as an engineering owner: "Adding an extra load on mobile is extremely costly." So touch layers stay in their component's own module, with no chunk of their own. What we measured on this head (55466e9):
A static version is on vjeux/astryx Whether to take it is your call. |
|
A screencast-cadence note on this head's |
… lock The test asserted the gesture host's inline user-select at rest, which the host's newer model (spec:AST-094 FR41) no longer writes there: it locks selection for a held press only and lifts the lock with the finger, while the trigger's own style keeps selection off at rest (spec:AST-017 FR59). It now checks the trigger's computed value at rest, the host's inline lock during a held finger short of the commit, and the rest value again after the lift, so it holds under the host on this branch and under FR41's. The ContextMenu comment says the host locks for a held press.
There was a problem hiding this comment.
Approval is on hold until an engineering owner decides two additions that no current spec covers: the page scroll lock under a touch-opened ContextMenu popover (spec:AST-094 names a page lock only for modal presentations, and its FR32 wants an outside pan to close an anchored menu) and the new public useLongPress stages option with its start(point, time) argument. An engineering owner can provide or identify the governing spec for them, or record the decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever that decision, these need changes:
- Rebase onto
mainand land or retarget the predecessor pull requests so this diff holds only the ContextMenu change; it carries about 36,000 authored lines and now conflicts withmain. - Take the text-selection lock only where a hold does something (
spec:AST-094FR41 and DEC-9), and keep touch motion roles out ofdefineThemeuntil the public set is decided (FR4 and DEC-11). - Under FR32 and FR33, show the menu beside the lifted trigger, follow the sheet without a lift, keep the lift through the whole drift allowance, hand the opening finger to the menu, and close on an outside pan with the outside tap reaching nothing.
- Build the trigger lift as the shared lift-from-trigger module (
architecture:layer-runtimeINV15), keep the pressable marker off a disabled trigger, replace the touch layer's handle Effect, and correct the changesets that say no component uses this code. - Add real-device iOS Safari and Android Chrome evidence for the claims about those browsers, and explain or fix the growth of the
ContextMenuItemimport from 16.4 KB to 53.4 KB gzip.
[Automated review]
| @@ -283,6 +301,9 @@ function onPointerDown(event: PointerEvent): void { | |||
| gesture: idlePressGesture(), | |||
| pointerId: event.pointerId, | |||
| timer: null, | |||
| // A held finger never starts text selection on the surface (UIKit's | |||
| // controls and cells never do), on any coarse pointer. | |||
| unlock: lockSelection([element], event.target), | |||
There was a problem hiding this comment.
spec:AST-094 FR41 keeps native selection on a label or plain text whose hold does nothing ("such as a checkbox row's label"), and DEC-9 rejects "suppressing selection on every press-tracked control". This lock runs for every usePressFeedback surface; take it only on elements whose hold does something.
| readPresentation(presentation, {whenOmitted: 'touch', compact}) | ||
| .touchModes, | ||
| ); | ||
| openAtLocalPoint(local.x, local.y, triggerRef.current, 'menu'); |
There was a problem hiding this comment.
FR33 asks the menu to sit "beside" the lifted trigger. Anchoring it at the finger inside the trigger draws it over the card instead.
| ); | ||
| // The page stays put while a menu a finger opened is up, as it does under | ||
| // UIKit's context menu. A sheet locks the page itself. | ||
| useScrollLock(isOpen && isTouchOpen && !usesBottomSheet); |
There was a problem hiding this comment.
No current record covers a page scroll lock under a non-modal popover (AST-094 FR19 names one only under a modal presentation). With dismissal on mousedown only, a pan outside a touch-opened menu then neither scrolls the page nor closes the menu, which FR32 requires. This lock waits on an engineering owner's decision.
| // Under the touch model the trigger is a pressable surface of core's | ||
| // one press machine (utils/pressFeedback.ts); the touch layer installs | ||
| // the machine and its press feedback follows the pressed state. | ||
| {...(touchModes ? pressableProps : null)} |
There was a problem hiding this comment.
With isDisabled this marker still makes the trigger a surface of the shared press controller, so a finger starts its onset timer and selection lock. FR24: "while a touch presentation is disabled, no touch-only listener, observer or timer is active". Spread it only when touchModes && !isDisabled.
| }, | ||
| ); | ||
|
|
||
| useEffect(() => { |
There was a problem hiding this comment.
architecture:react-component-runtime INV3: a new Effect names the external system it synchronizes. This one hands ContextMenu a handle that sets isTouchLayerReady state; a ref ContextMenu owns (useImperativeHandle) with readiness read from the loaded module would avoid the Effect.
| * ``` | ||
| */ | ||
| motion?: MotionScaleConfig; | ||
| motion?: MotionConfig; |
There was a problem hiding this comment.
AST-094 FR4 and DEC-11 keep touch motion roles internal until the public motion-token set is decided ("a theme cannot override them yet"). This field makes them theme-settable, with docs, the template and an interaction case to match.
|
An offer for this pull request's touch layer, because a review on #8228 asks which external system its handle Effect keeps in step. Branch Separately: once this branch takes main (#8257: themes do not set motion roles), the sentences saying a theme may retune the press feedback (both changesets, |
|
Your 17:05Z touch model (#8464 (comment)) has components import the gesture and touch modules directly, with the bundler keeping one copy per page. That replaces the Measured on this head (bf001e6) with the size report's tool (
The offer is
Results on 16dc55e: ContextMenu jsdom 146/146; ContextMenuLongPress Chromium 20/20, WebKit 17/17; core typecheck and lint clean. Whether to take it is your call. |
|
Posted by Cindy's agent on her behalf. Cindy's decision on context menus: a public, framework-agnostic For this PR, a small change: |
…k#8201 The touch layer is imported directly, so it runs from the first render under the touch model. Where both sides edited a header, the offer's loading wording is kept along with the lift; the lazy loader and its test go with the offer.
…k#8201 The press constants' entry keeps this stack's wording (no theme surface) and takes the offer's correction: ContextMenu's touch timeline uses them.
Depends on #8065, the gesture stack (#8336 on #8315, #8309, #8270 and #8076) and #8298 (the presentation resolver); review the last five non-merge commits.
Evidence
iOS 26.2 Safari simulator; HUD: ms since the touch, clicks; dashed: the card at rest.
Before (main): no feedback, the menu at ~500 ms, first row lit; the closing tap clicks.
After:
Android 15 emulator, Chromium 158:
presentation="popover", today's long press:Second finger (Chromium):
User need
A held finger should open a context menu on UIKit's sequence: growth from 150 ms, the menu at ~0.74 s, the page still.
Problem and solution fit
One touch model where the primary pointer is coarse (AST-094 FR13), resolved by #8298's
usePresentation(presentation, {whenOmitted: 'touch'}). Where it is fine, and withpresentation="popover"on every device (INV16), a finger keeps today's 500 ms long press: no recognizer, no growth.useLongPress's detector with chore(motion): ContextMenu's touch timeline and press curve, measured on iOS 26.2 #8065's values: the commit at 400 ms claims the finger (no click, no scroll), the menu opens at 735 ms, or at a lift after 400 ms. A drift past 11.5 px, a second finger, an early lift or a scroll opens nothing. The recognizer takes a finger or a pen (allowedPointerTypes, UIKit's allowedTouchTypes).utils/pressFeedback.ts); the growth starts at its "on" (150 ms) and springs back when the press ends with no menu. A context-menu press profile is proposed to the controller's owner; follow-up: a press-state callback replaces the growth's MutationObserver.presentation="popover"opened nothing in iOS Safari (nocontextmenufor a long press).design:reduced-motion, through the animator): no growth, the menu on time.Current specification
component:ContextMenuis a draft; AST-094 (FR4, FR13, FR25, FR33) anddesign:reduced-motiongovern.Owner decisions, proposed; pending owner review:
presentationmeans the touch model under a finger (AST-017 FR3).Public delta and caller burden
useLongPresstakesstagesandstart(point, time); ContextMenu'spresentationdefault becomes the touch model. Touch layer:ContextMenu/ContextMenuTouch.ts, its one import site. Size: +2684/−213, about 60% tests.Scope
Testing
pnpm vitest run packages/core/src/{ContextMenu,hooks,utils,Layer,gestures,motion}: 2106 pass. The pressable coverage guard counts a script that follows the pressed state (getAttribute(PRESSED_ATTRIBUTE)) as a press arm, as ContextMenu's growth does. The touch suite runs on iOS and Android stubs alike.presentation="popover"under a finger opens at 500 ms through today's long press (failed before the fix on both stubs: no menu), and a drift past 10 px or an early lift opens nothing. Where the primary pointer is fine, a finger opens at 500 ms with no growth, no scroll lock and no handoff, and a right-click keeps the cursor menu. The same finger opens at 735 ms coarse and at 500 ms fine.useLongPresscovers stages, tolerance after the long press, and deadlines counted from a given time on a given clock.pnpm test:interaction ContextMenuLongPress: Chromium 19/19, WebKit 16/16 (+3 Chromium-only; the fine-primary touch case is skipped, as both engines report a coarse primary pointer whenever touch is emulated), under each engine's own finger with no iOS shim:presentation="popover": the menu at 500 ms (not 735), with no growth;check:changesets, the experimental-isolation golden (no experimental surface), the table-import rule.