Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
5edeba7 to
4038ef0
Compare
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approval is waiting on an owner decision. Draft spec:AST-094 is the only spec behind the lab NavigationStack and the two new experimental import paths, so an engineering owner needs to approve FR1–FR23, DEC-1 and DEC-2, together with the amendments it proposes to current records, by commenting /approve-spec 4038ef0c4221e2411422828cc7576237ef625899 on this pull request, or else name the record that should govern; the author may do so as an engineering owner. Whatever that decision, these changes are needed:
- In a real browser, focus falls to the page body after every pop, because the stack tries to restore focus while the revealed screen is still
inert. - The
adaptivequery change inuseAdaptivePresentation.tschanges released menu and selector behavior againstcomponent:SelectorDEC-1, and belongs in its own pull request. - The UIKit table's sourcing test fails on
contentPopHysteresis, and CI rejects the ShadCN route lock and the CLI official package list, which both need regenerating. - Against
mainthis is 27,062 authored lines; landing the stacked predecessors first would leave the 1,974-line NavigationStack commit.
[Automated review]
| ); | ||
| if (under != null) { | ||
| settle(under, 'top'); | ||
| focusAfter('pop', top); |
There was a problem hiding this comment.
This runs right after setView(… leaving: null) but before React commits it, so the revealed screen is still inert and source.focus() does nothing; in Chromium focus ends on the body after Back, both from the keyboard and from a pointer. Restoring focus after the commit that clears inert, with a fallback to the revealed title, would keep the documented behavior.
| * @source measured: UIKit lab (injected host app), iOS 26.2 simulator, | ||
| * iPhone 17 Pro, UINavigationController.contentSwipe began after 27–30 pt | ||
| * of travel for drags at or under 600 pt/s, Oct 23 2026 | ||
| * @measure the exact threshold and the faster start: at 1000 pt/s the swipe |
There was a problem hiding this comment.
uikit.test.ts requires @measure M-<ID> with the ID listed in motion/MEASUREMENTS.md; this free-text tag fails "every value is sourced (law P2)" locally and in CI test-ui (1/4).
| // and large touch displays stay anchored, phones in either orientation get | ||
| // the sheet. The query is the shared touch presentation's | ||
| // (utils/touchPresentation.ts). | ||
| export const COMPACT_TOUCH_PRESENTATION_QUERY = COMPACT_TOUCH_QUERY; |
There was a problem hiding this comment.
This swaps the surface released menus and selectors open: a coarse-pointer phone in landscape now gets a modal sheet, and a 744 px tablet in portrait an anchored popover. The current Selector record says adaptive keeps its width-and-pointer query, so this probably belongs in its own pull request with that owner's decision.
| whiteSpace: 'nowrap', | ||
| overflow: 'hidden', | ||
| textOverflow: 'ellipsis', | ||
| outline: 'none', |
There was a problem hiding this comment.
After a keyboard push, focus lands on this title, and with outline: 'none' nothing shows where it is; the interaction-modality architecture expects the shared focus indicator after keyboard input.
| // Commit the pop; the transition it triggers continues from here | ||
| // at the finger's speed. | ||
| releaseRef.current = {velocity: v}; | ||
| onPathChangeRef.current(pathRef.current.slice(0, -1)); |
There was a problem hiding this comment.
If the app keeps path here (for example to guard unsaved edits), nothing springs the cards back, and the top card stays where the finger left it.
| const previous = rendered[index - 1]?.element.props; | ||
| return ( | ||
| previous?.backTitle ?? | ||
| previous?.title ?? |
There was a problem hiding this comment.
With ??, a previous screen titled "" gives Back an empty accessible name; the catalog's "Back" is meant for exactly that case.
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. Bundle Size SummaryGzip figures measure each package's entry file, not the code an import pulls in.
Accessibility AuditStatus: No accessibility violations detected. Visual Regression55 of 502 shot(s) changed. A change here is a question, not a failure: check whether the after is the
and 35 more. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
4038ef0 to
4771de3
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner deciding whether the draft touch-presentation spec (AST-094: FR1–FR23, DEC-1 and DEC-2, with the amendments it proposes to current records) governs the new motion and gesture experimental subpaths, and which spec governs the lab NavigationStack's own API and focus behavior; an engineering owner records that decision by commenting /approve-spec 4771de31dc836de85c69c3314ae5fc05071362c1 on this pull request, and the author may do so if they are an engineering owner.
- Please drop the
adaptivepresentation query change from this pull request, since it changes where five released menus and selectors open a bottom sheet against the current Selector spec. - After a pop, focus lands on the page body instead of the control that pushed the screen, so please restore it once the revealed screen is no longer inert.
- Please add the
@astryxdesign/cliChangeset the lint job asks for, give the focused bar title a visible focus indicator, and retarget once the predecessor pull requests land so the diff is the NavigationStack commit alone.
[Automated review]
4771de3 to
5743dab
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner deciding whether the draft touch-presentation spec (AST-094: FR1–FR23, DEC-1 and DEC-2, with the amendments it proposes to current records) governs the new motion and gesture experimental subpaths, and which spec governs the lab NavigationStack's own API, bar and focus behavior; an engineering owner records that decision by commenting /approve-spec 5743dabda58f55e296678b3f8b5d06f55c19106f on this pull request, and the author may do so as an engineering owner. Whatever that decision, these changes are still needed:
- Please drop the
adaptivepresentation query change, which moves where released menus, selectors and their sub-menus open against the current Selector spec. - After a pop, focus lands on the page body instead of the control that pushed the screen, so please restore it once the revealed screen is no longer inert, and give the title focused after a keyboard push a visible focus indicator.
- Please spring the cards back when the app declines a released swipe, fall back to the catalog "Back" for an empty previous title, and correct AST-094's citation of AST-090, which does not exist.
- Please land the predecessor pull requests (or retarget) so this diff is the NavigationStack commit alone, and get a green
lintrun.
[Automated review]
| 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 is not on main (no record, no reference), so FR7 departs from a record the approver cannot read; the same citation repeats in Current-state impact. Either name the record that exists, or drop the departure until it lands.
| return; | ||
| } | ||
| } | ||
| layersOf(key)?.titleElement?.focus({preventScroll: true}); |
There was a problem hiding this comment.
On a pop this is called with the popped screen's key (focusAfter('pop', top)), so the fallback focuses the leaving screen's own title, which is still inert and about to unmount. The fallback probably wants the revealed screen (under), focused after the commit that clears inert.
5743dab to
0ac171f
Compare
… pops to the root A push removes the covered screen's title 0.54 s in; the new proof blocks the main thread for 900 ms from the push's first frame and checks the title is gone on time (it lingered until the block ended before meta#8107's fix). The stories' screens with nothing deeper get a Done row that pops back to the root in one transition, so the multi-level pop can be filmed.
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: draft spec:AST-094 (FR1-FR23, DEC-1, DEC-2) is unapproved, and no record yet governs NavigationStack's own API, bar and focus behaviour, or where experimental subpaths that no component owns should live under spec:AST-017 FR21. An engineering owner can record that decision by commenting /approve-spec 0ac171f6f19169a4a57ab4f43dd7fa60b86a996b on this pull request, and the author may do so as an engineering owner. Independently of that decision, these need changes:
- Focus is lost to the page after every pop, and the pushed title shows no focus indicator after keyboard input (
NavigationStack.tsx:927-932,:238). - The content back swipe takes rightward drags away from nested horizontal scrollers, and a declined swipe leaves both screens frozen mid-pop (
NavigationStack.tsx:1157-1176,:1098-1102). - The
presentation="adaptive"query change contradictsSelector.spec.mdDEC-1 and belongs in its own pull request, and at 28,054 authored lines the stack should land as separate pull requests.
[Automated review]
| ); | ||
| if (under != null) { | ||
| settle(under, 'top'); | ||
| focusAfter('pop', top); |
There was a problem hiding this comment.
This runs before React commits leaving: null, so every layer is still inert and source.focus() is a no-op: after Back, focus ends on the page body. Move focus after the commit that clears leaving, and fall back to the revealed screen's title rather than the popped one.
| whiteSpace: 'nowrap', | ||
| overflow: 'hidden', | ||
| textOverflow: 'ellipsis', | ||
| outline: 'none', |
There was a problem hiding this comment.
outline: 'none' hides the focus that a keyboard push moves to this title (it matches :focus-visible); interaction-modality INV1 says programmatic focus after keyboard input shows the shared indicator.
| new PanGestureRecognizer({ | ||
| name: 'NavigationStack.contentBackSwipe', | ||
| direction: 'right', | ||
| hysteresis: CONTENT_CLAIM_PX, |
There was a problem hiding this comment.
A one-way pan without scrollEdge claims the touch after 5 px without checking nested scrollers, so a horizontally scrolled carousel inside the screen can no longer be dragged back toward its start. scrollEdge: true with claimDistance: null lets it begin only when nothing under the finger can scroll right.
| releaseRef.current = {velocity: v}; | ||
| onPathChangeRef.current(pathRef.current.slice(0, -1)); |
There was a problem hiding this comment.
If the app declines this path change, nothing resets the layers: both screens stay where the finger left them and releaseRef stays armed for the next pop. Spring back as a cancel when the path has not changed by the next render.
0ac171f to
8af05a6
Compare
… pops to the root A push removes the covered screen's title 0.54 s in; the new proof blocks the main thread for 900 ms from the push's first frame and checks the title is gone on time (it lingered until the block ended before meta#8107's fix). The stories' screens with nothing deeper get a Done row that pops back to the root in one transition, so the multi-level pop can be filmed.
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: draft spec:AST-094 (FR1-FR23, DEC-1, DEC-2) is unapproved at this head, its FR4 says touch physics are not themable while this head adds theme motion roles that retune them, and no record yet governs NavigationStack's own API, bar and focus behaviour. An engineering owner records the decision by commenting /approve-spec 8af05a61875de26eb7ba9cc15b32652bad39348f on this pull request, and the author may do so if they are an engineering owner; if the theme roles are the intended direction, FR4 and DEC-1 need rewriting first. Independently of that decision, these need changes:
- Focus is lost to the page after every pop, and the pushed title shows no focus indicator after keyboard input (
NavigationStack.tsx:936-941,:240). - The
presentation="adaptive"query change swaps the popover and the sheet in five released components against the Selector record's DEC-1, so it belongs in its own pull request. - CI
test-node (1/4)fails because the CLI's stable-output golden for the motion docs topic was not regenerated after the NavigationStack commit. - The content back swipe takes rightward drags from nested horizontal scrollers, and a declined swipe leaves both screens frozen (
NavigationStack.tsx:1174-1187,:1107-1111). - At 30,121 authored lines, the motion, gesture, theme-role and harness foundations should land as their own pull requests.
[Automated review]
| measures (0.55 for a scroll view and a sheet), and a release MUST pick its | ||
| rest point by projecting its velocity the way its UIKit counterpart does: | ||
| with a deceleration rate, or with a measured projection time. | ||
| - **FR4 — Physics are not themable in touch presentations.** A touch |
There was a problem hiding this comment.
FR4 says a touch presentation reads its motion from the table on every theme, but this head lets themes retune it: the animator resolves every table spring under the element's theme (packages/core/src/motion/animator.ts:1301-1303), and defineTheme({motion}) takes springs, durations and curves. One of the two has to change so the record an owner approves describes what ships; DEC-1's rejection of per-theme tuning and the FR4 verification row would change with it.
| * ``` | ||
| */ | ||
| motion?: MotionScaleConfig; | ||
| motion?: MotionConfig; |
There was a problem hiding this comment.
This widens the stable DefineThemeInput.motion under a [feat] Changeset, with keys that are paths into the experimental uikit table, which may be renamed in a patch release. expandMotionRoles accepts an id nothing registers, so a renamed role would silently stop applying in a released theme. spec:AST-017 FR21 keeps a surface like this behind a marked experimental boundary.
| * is everything else. Pair `ios` with `pointer: 'coarse'` for a touch | ||
| * profile, such as touch motion tuned per platform. | ||
| */ | ||
| platform?: 'ios' | 'other'; |
There was a problem hiding this comment.
The theme-authoring-contract record's change coupling says an adaptation change preserves the fixed condition vocabulary; adding platform changes that vocabulary, so it needs the record amended and an owner's decision first.
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.
There was a problem hiding this comment.
Approval is waiting on an engineering owner's decision: no current spec governs the Lab NavigationStack (its API, bar, back swipes and focus behaviour, and the motion roles spec:AST-094 FR4 asks a component record to name for its five navigation springs), or the new stable isRtlElement export from @astryxdesign/core/hooks, which spec:AST-017 FR21 would keep internal. An engineering owner can record that decision by commenting /approve-spec 2cb97c4858b381e1af9f395fc407af4a9cede7d0 on this pull request; the author may do so as an engineering owner. Whatever the decision, these need changes:
- The back swipe averages the last three pan velocities and ignores the velocity's sign, so it can pop after a pause or while moving back (
spec:AST-100FR2/FR3,spec:AST-094FR37). - After a click or tap on a row's text, a pop to the root leaves focus on the page body, because the recorded source is the row's label rather than its button.
- A content swipe first moves the screen about 11 px against the finger at the pan's claim, and a runtime change of writing direction stops it from popping.
- 27,558 of the 30,007 authored lines come from the unmerged dependency stack (#8360, #8562); landing that first lets this pull request be reviewed on its own.
[Automated review]
| const recent = swipe.velocities.slice( | ||
| -navigation.interactivePopVelocitySamples, | ||
| ); | ||
| v = recent.reduce((sum, value) => sum + value, 0) / recent.length; |
There was a problem hiding this comment.
The mean of the last three readings is a second velocity estimate: after a still pause the pan reads 0 at the lift, but readings of 2, 2 and 0 widths/s average 1.33, so a lift at 30 % pops (0.3 + 0.35 × 1.33 = 0.77). spec:AST-100 FR2 says a still finger reads 0 and "none reads another estimate", and FR3 that "a component never derives a second velocity to compare against". Pass popVelocity(recognizer.velocity().x, width, direction) at the lift and drop the buffer.
| return ( | ||
| progress + | ||
| navigation.interactivePopFinishProjection * velocityWidthsPerSecond > | ||
| navigation.interactivePopFinishThreshold | ||
| ); |
There was a problem hiding this comment.
This commits a release that is moving back whenever the projection stays above half: shouldFinishPop(0.8, -0.5) is 0.625. spec:AST-094 FR37: "A release whose velocity points back toward the start MUST cancel, whatever the travel so far." Return false for a negative velocity before projecting, and add a [0.8, -0.5, false] row to the test table.
| const rememberActivation = useCallback((event: SyntheticEvent) => { | ||
| if (event.target instanceof Element) { | ||
| lastActivationRef.current = { | ||
| target: event.target, |
There was a problem hiding this comment.
event.target is often not the control: a click or tap on a row's text lands on the label inside ListItem's button, and on the pop focus() on it does nothing, so focus stays on body (reproduced in Chromium: click General's text, then Back, and document.activeElement is BODY). Record the closest focusable ancestor, and fall back to the revealed title when focus does not land.
| (direction === 'rtl' ? -1 : 1) * recognizer.translation().x; | ||
| // Back past where it started, the screen follows with resistance | ||
| // (progressFromTravel). | ||
| const travel = along - deadZone; |
There was a problem hiding this comment.
Inside the 17 px dead zone this travel is negative, and progressFromTravel rubber-bands it, so the screen moves against the finger: with real touch input in Chromium it jumped to −11.36 px at 11 px of travel and was back at 0 only at 27 px. Hold travel inside the dead zone at 0, for example along >= deadZone ? along - deadZone : Math.min(0, along).
| useLayoutEffect(() => { | ||
| content.direction = | ||
| stackRef.current?.direction() === 'rtl' ? 'left' : 'right'; | ||
| }, [content, stackRef]); |
There was a problem hiding this comment.
content and stackRef never change, so this runs once. After dir="rtl" was set on the stack at runtime, neither a leftward nor a rightward content swipe popped in Chromium (design:bidirectionality DR13). Set the direction from stack.direction() when each touch begins, for example in shouldReceiveTouch.
| layers?.barDim?.stop(); | ||
| } | ||
| runningRef.current = null; | ||
| return width > 0 ? Math.abs(x) / width : 0; |
There was a problem hiding this comment.
Math.abs drops the sign of the presentation value: a finger that catches the return from a release past the start (x < 0 in LTR) continues from +|x|, a jump of 2|x|. spec:AST-094 FR6 asks for a catch "at the value on screen". Return the signed progress, (direction === 'rtl' ? -x : x) / width.
| name: 'isInteractivePopEnabled', | ||
| type: 'boolean', | ||
| description: | ||
| "Whether the back swipe pops: a sideways drag anywhere in the content, and in a web app opened from the home screen also a swipe from the leading screen edge. In a browser tab that edge stays the browser's own back swipe. The back swipe is an iOS gesture: on other touch devices (Android's system back owns both screen edges) and with a mouse, Back is the bar's button.", |
There was a problem hiding this comment.
The content swipe runs under any coarse primary pointer, Android included (NavigationStackTouch.ts:18-20, :241), so "on other touch devices … Back is the bar's button" is wrong for Android. Describe the content swipe on every touch device and the edge swipe only in a home-screen web app.
| // Past the start the screen follows at a share of the finger, as UIKit's | ||
| // does (`navigation.interactivePopRubberBand`, measured in batch 62); | ||
| // never past the far edge. | ||
| return p < 0 ? p * navigation.interactivePopRubberBand : Math.min(1, p); |
There was a problem hiding this comment.
spec:AST-094 FR3 asks a drag past an edge to resist with UIKit's rubber band (1 − 1 ÷ (x·c ÷ d + 1))·d; a flat 0.71 moves a 120.6 px overshoot on a 402 px stack 85.6 px instead of 70.6 px. Core's rubberBand, already re-exported from internal/motion, with c = 0.71 and d = the width, keeps the measured coefficient.
| const width = stack.width(); | ||
| const direction = stack.direction(); |
There was a problem hiding this comment.
These read clientWidth and the computed direction on every finger move, and setProgress reads both again; spec:AST-094 FR9 allows "no layout read after the gesture begins". Read both once at began and keep them on swipeRef.
Depends on #8360 and #8562. Review only this PR's change.
User need
What led here: we are bringing Astryx's touch components to iOS quality on the mobile web. Phone layouts need iOS's drill-down navigation: each screen pushes the next, a back swipe follows the finger and can be cancelled, and a push can be grabbed mid-flight. AppShell and MobileNav switch sections; nothing in Astryx stacks screens.
Problem and solution fit
NavigationStackrenders the app'spath, oneNavigationScreenper entry; covered screens stay mounted, scroll kept, but inert. Screens move like UIKit's: a measured push spring, bars that ride with their screens, and a back swipe from anywhere in the content, tracked 1:1 and finished by UIKit's release rule. Focus goes to the new title, and back to the pushing control after a pop.Current specification
spec:AST-094: touch keys on a coarse primary pointer (FR13); a browser tab keeps its edge swipe (FR22), so the stack's runs only in a home-screen web app. Lab placement and API are proposed, for the owner's review.Public delta and caller burden
Lab:
NavigationStack,NavigationScreen,useNavigationStack; the caller passespathandonPathChange. Core: six measureduikittable entries,isRtlElementfrom its hooks, and the locale key@astryx.navigationStack.back.Design and alternatives
Not here: large titles (#8185), row selection across a push (#8114), search (#8204).
Evidence
iOS 26.2 simulator: push, bar and back, slow swipe springs back, moving back cancels, back past its start, paused fast swipe finishes, flick, content swipe, 600 ms main-thread block, right-to-left, grabbed mid-push, pop to root. Chromium: edge swipe in a home-screen app, push during a push, a sideways strip, declined pop, keyboard focus, pop then swipe. Android 15 emulator: push and pop, content swipe, slow swipe, flick.
Scope
Testing
In Chrome's device toolbar (a phone, touch), "Lab/NavigationStack › Settings":
What I ran: the unit tests and root typecheck passed; #8108's real-browser proofs passed in Chromium and WebKit.
Recorded on the iOS 26.2 simulator and the Android 15 emulator. Includes #8562 (Core's internal entry points); if those land differently, this follows.