Repository navigation
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
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 |
f8fe6c1 to
26cb62a
Compare
![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 also needs a few changes. An engineering owner approves or rejects the draft spec AST-094 by commenting /approve-spec <full head SHA> on this pull request (the author may do so as an engineering owner), names the record that governs the TabBar's own presentation (the arrow keys skipping a disabled tab, and the collapsed bar exposed as one button), and decides the new adaptive-presentation threshold for DropdownMenu, ContextMenu, MoreMenu, Selector and MultiSelector. The two points marked "pending owner review" are already required by the current focusable-disabled spec (AST-085 FR1, FR2 and FR5), so they need no separate decision.
- Land the stacked predecessors, or retarget onto #8192, so this pull request's diff is its own 358-line commit instead of about 31,900 authored lines.
- A finger landing on a disabled tab still lifts the lens onto it and draws it selected (
useTabBarLens.ts), which AST-085 FR6 rules out for a disabled control. - Collapsed, the empty "Sections" tab list stays in the accessibility tree beside the circle button, so the bar is not yet one element; making the capsule itself inert while collapsed would fix it.
- The
minimizeBehaviorJSDoc inTabBar.tsxstill says focusing a tab expands the bar.
[Automated review]
| {spring: tabBar.lensTravel}, | ||
| {at, ...MOTION}, | ||
| ); | ||
| lift(true, at, size); |
There was a problem hiding this comment.
A finger that lands on a disabled tab still gets this travel and lift, and the copy under the lens draws the tab in the selected look before choose() refuses it three frames after the lift. AST-085 FR6 says hover, pressed and drag affordances must not appear on a disabled control; passing the disabled indices into this hook and skipping the travel and lift for them would conform.
| ) : null} | ||
| <div | ||
| ref={mergedCapsuleRef} | ||
| role="tablist" |
There was a problem hiding this comment.
Collapsed, every tab here is inert, but this role="tablist" keeps its aria-label, so Chromium still exposes an empty "Sections" tab list beside the circle button. Making the capsule itself inert while collapsed (when there is no search tab) would give assistive technology the one element the docs describe.
| /** | ||
| * Whether scrolling the page down collapses the bar into a circle holding | ||
| * the selected tab's icon (UIKit's `tabBarMinimizeBehavior`): reaching the | ||
| * top of the page, a tap on the circle or focus on a tab expands it. Under |
There was a problem hiding this comment.
Collapsed tabs are now inert, so focus can no longer reach a tab to expand the bar. TabBar.doc.mjs already says "reaching the top of the page or activating the circle expands it"; this JSDoc and the expand comment in useTabBarMinimize.ts could say the same.
| // 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 moves presentation="adaptive" for DropdownMenu, ContextMenu, MoreMenu, Selector and MultiSelector from (max-width: 768px) and (pointer: coarse) to a viewport narrower than 744px or shorter than 500px. No current record names either threshold, so it needs an engineering owner's decision, and the updated tests import this constant rather than pinning a value.
26cb62a to
e8fd056
Compare
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved, and it also needs a few changes. An engineering owner approves or rejects the draft spec AST-094 by commenting /approve-spec <full head SHA> on this pull request (the author may do so as an engineering owner), names the record that governs the TabBar's own presentation (the arrow keys skipping a disabled tab, and the collapsed bar exposed as one button), and decides the new adaptive-presentation threshold for DropdownMenu, ContextMenu, MoreMenu, Selector and MultiSelector. The two points marked "pending owner review" are already required by the current focusable-disabled spec (AST-085 FR1, FR2 and FR5), so they need no separate decision.
- Land the stacked predecessors, or retarget onto #8192, so this pull request's diff is its own 325-line commit instead of about 32,300 authored lines.
- A finger landing on a disabled tab still lifts the lens onto it and draws it selected (
useTabBarLens.ts), which AST-085 FR6 rules out for a disabled control. - Collapsed or searching, an empty "Sections" tab list stays in the accessibility tree beside the circle button; making the capsule inert whenever no tab in it is reachable would fix it.
- The
minimizeBehaviorJSDoc inTabBar.tsxstill says focusing a tab expands the bar, and with no tab selected the collapsed circle has no accessible name.
[Automated review]
| // Collapsed, the circle is the bar's one element for assistive | ||
| // technology, as on iOS: the selected tab, collapsed (while | ||
| // searching, the tab it returns to). Expanded, it is hidden. | ||
| aria-label={isMinimized ? selectedItem?.label : undefined} |
There was a problem hiding this comment.
With no tab selected (value matching no tab, a state the bar handles at :1061 and :1143), selectedItem is null, so the collapsed circle is a focusable button with aria-expanded="false" and no name. chooseCircle then skips the focus move, leaving focus on the circle as it turns aria-hidden. Naming it (the bar's label, say) and focusing the tab that holds the tab stop after expanding would fix both.
…-touch-model restack)
…-touch-model restack; the before clip is meta#8192's build)
…-touch-model restack); the before clip is meta#8192's build
e8fd056 to
1bf4927
Compare
github-actions
Bot
added
the
needs:design-review
1bf4927 to
93b1eb3
Compare
There was a problem hiding this comment.
This needs engineering-owner decisions before it can be approved, and it also needs changes. An engineering owner approves or rejects the draft spec AST-094 by commenting /approve-spec <full head SHA> on this pull request (the author may do so as an engineering owner), names the record that governs the TabBar's own presentation (the arrow keys skipping a disabled tab and the collapsed bar as one button), and decides on the theme motion roles that AST-094 FR4 rules out, the isRtlElement and reducedMotion.stylex exports, useFingerScroll, and the selection lock on stable press surfaces.
- Land the stacked predecessors, or retarget onto #8192, so this pull request's diff is its own 492-line commit instead of about 42,000 authored lines.
- Minimized with a search tab, the search circle stays visible but inert, so a tap on it reaches the page behind the bar (
TabBar.tsx). - A drag still lifts the lens onto a disabled tab and draws it selected, which AST-085 FR6 rules out (
useTabBarLens.ts). - The press-surface selection lock changes stable components, including the iOS callout on
Link, so it needs a stable Changeset rather than[experimental](AST-017 FR22). pr-a11yfails on the NoSelection story's empty heading, the theme template documents aplatformadaptation axis that does not exist, and two release notes misdescribe their surface.
[Automated review]
| aria-orientation="horizontal" | ||
| // Collapsed (minimized, or while searching), none of its tabs is | ||
| // reachable: the circle stands for the bar. | ||
| inert={isMinimized} |
There was a problem hiding this comment.
The search tab (:1154-1201) is a child of this tablist, so while the bar is minimized with a search tab, the search circle stays visible (the browser test at __tests__/TabBar.interaction.browser.spec.ts:2484 expects both circles) but is inert: since the bar's root and wrapper take no pointer input, a tap on it falls through to the page behind the bar, and screen readers no longer find it until the bar expands. On the previous commit the same tap chose search. Making the tablist inert only when none of its tabs is reachable (no search tab, or while searching) and leaving the item tabs individually inert would keep the circle operable; a test that taps the minimized search circle would hold it.
| if (press.isIgnored) { | ||
| if (!press.isDragging) { | ||
| return; | ||
| } | ||
| // A drag from a disabled tab: the press counts from here (the lens, | ||
| // when there is one, lifts and chases). | ||
| press.isIgnored = false; | ||
| if (press.hasLens && selected >= 0) { | ||
| lift(true, at, press.size); | ||
| } | ||
| } | ||
| if (!press.hasLens || selected < 0) { | ||
| return; | ||
| } | ||
| body.animator.animate( | ||
| {x: lensTarget(x, press.centers) - press.centers[selected]}, | ||
| {spring: press.isDragging ? tabBar.lensTrack : tabBar.lensTravel}, | ||
| {at}, | ||
| ); | ||
| playCopy(at); |
There was a problem hiding this comment.
Once a press drags, the lens lifts and chases the finger onto any item, including a disabled one, and the copy under the lens draws that item in the accent, semibold selected look (TabBar.tsx:719-722, :1232-1248) until the lift settles back. AST-085 FR6 says disabled paint applies and drag affordances must not appear on a disabled control. Holding the lens on the nearest enabled position while the finger is over a disabled tab, and giving a disabled item's copy its disabled paint, would conform.
| @@ -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.
This lock runs for every usePressFeedback surface on a touch or pen press, so it changes stable components such as Link, Button, Item, Selector and CheckboxInput; on a Link it also removes iOS's link callout. AST-017 FR22 keeps stable runtime changes out of the [experimental] category used by .changeset/touch-selection-lock.md. A stable category with a release note naming the affected components, and keeping the callout on elements with href, would address it.
| * `from` includes its point; `below` excludes it. The other supported axes | ||
| * are primary-pointer precision, contrast preference, and motion preference. | ||
| * are primary-pointer precision, contrast preference, motion preference, and | ||
| * platform (`ios` for the browsers of iPhone and iPad, `other` for the rest). |
There was a problem hiding this comment.
The theme code at this head has no platform condition, and AST-012 FR2 limits a when object to width, height, pointer, contrast and motion, so a rule written as this line describes would be rejected. Dropping the platform sentence would fix it.
| function Screen({title, reselects}: {title: string; reselects: number}) { | ||
| return ( | ||
| <div style={{padding: '16px 16px 104px'}}> | ||
| <h1 style={{margin: '8px 0 16px', fontSize: 28}}>{title}</h1> |
There was a problem hiding this comment.
With no tab selected (the NoSelection story) the title is empty, and pr-a11y fails on this head with axe's empty-heading for lab-tabbar--no-selection. A heading text for that state, or no heading, would clear it.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [experimental] Two experimental subpaths for building touch presentations, outside the stable compatibility promise (they may change or be removed in a patch release). `@astryxdesign/core/motion/experimental` exports the compositor animator (`createAnimator`, `useAnimator`), UIKit's spring, rubber-band and cubic-bézier math, `resolveMotion` (a motion role's value under the element's theme), and the UIKit constants table as the read-only `uikit` namespace. `@astryxdesign/core/gestures/experimental` exports UIKit-style gesture recognizers (tap, long press, pan, screen-edge pan, swipe, pinch, rotation, hover), `useGestureRecognizer`, `usePressTracker`, `useTouchPresentation`, `readTouchPresentation`, `playHaptic` and `attachTapHaptic`, with the `GestureArena` and `VelocityStrategy` types their options reach. Nothing is added to the package root or to any other subpath. |
There was a problem hiding this comment.
packages/core/src/gestures/experimental.ts no longer exports VelocityStrategy, and it does export ScrollViewPanGestureRecognizer, which this note leaves out. AST-017 FR22 asks the release note to name the affected surface.
| export const COMPACT_QUERY = DEFAULT_COMPACT_DEFINITION.query; | ||
|
|
||
| /** Both: presentations such as a sheet in place of a popover. */ | ||
| export const COMPACT_TOUCH_QUERY = |
There was a problem hiding this comment.
This reads the default compact definition, so under a theme that overrides md the five adaptive components still switch at 768px, while .changeset/touch-presentation.md promises "the theme's md point" and AST-012 FR9 uses the effective md point. Either the note and docs say 768px, or the query comes from the active theme's breakpoints.
| useEffect(() => { | ||
| if (!isEnabled) { | ||
| setIsMinimized(false); | ||
| return; |
There was a problem hiding this comment.
This Effect resets isMinimized when minimizing turns off, which react-component-runtime INV1 asks to do during render rather than as a follow-up Effect, and the write names no external system (INV3). Adjusting the state during render when isEnabled turns false, as TabBar.tsx:885-890 does for the tab search returns to, would leave this Effect to the scroll watcher alone.
93b1eb3 to
d360ff4
Compare
The tap and the second finger's landing went out 20 ms apart on the test's wall clock, which a loaded box stretched until the lens had reached Profile before the finger landed. They now go back to back, and the hold is a wait after the landing.
… spring from rest The turn used to come after the page settled, when the accessory had almost stopped, so a carried and a dropped velocity looked alike. The drag now ends at rest and the circle is tapped at once, and the first frame back is compared with the expand spring from rest.
Holding every animation made the earliest one the sampling origin; when the bar's other layers started a frame before the field, the samples ran ahead of the spring by about half a pixel in WebKit.
…rt times The expand's first frame is checked against the expand spring started from the offset the accessory turns from, with the speed the collapse had at the turn. The turn's moment is the two animations' start times apart, so a late tap (a loaded box) moves the prediction with it instead of failing the case.
…arch field covers it Under a finger the active field spans the bar's row over the leading circle, which kept its tab stop and its name. It is inert while the field is active there, with a browser test (red first: the covered circle took focus).
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved, and it also needs changes. No current spec states the lab TabBar's own presentation (the arrow keys skipping a disabled tab, the collapsed bar as one circle button, and the motion roles its springs would need), so an engineering owner provides or identifies that spec and records the decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner. The disabled tab itself follows AST-085 on every selection path.
- The gesture host attaches recognizers only under a coarse pointer, but AST-094 FR19 and FR43 now require gestures for every pointer.
- A tab bar is a
family:action-groupsmember, so its lens should come from the shared action-group tracker, light nothing over a disabled tab, act on nothing when a finger lifts off the bar, and work with every pointer. - AST-099 FR1 and FR3 require tab bar search to position from the on-screen keyboard height, and nothing in the TabBar reads it.
- Land or retarget onto the stacked predecessors so this diff is its own 460-line layer instead of about 36,700 changed lines, move the
astryxStylexfix, the unused press-paint exports and the host's unusedactionGroupoption to their own pull requests, and add an accessibility-tree check for the disabled tab (AST-085 FR5).
[Automated review]
| * | ||
| * ONLY WHERE THE PRIMARY POINTER IS COARSE | ||
| * | ||
| * - Recognizers attach, and the host registers listeners, only while the |
There was a problem hiding this comment.
This follows spec:AST-094 FR19's earlier wording. Current FR19 says "Recognizers attach for every pointer, with FR43's exceptions", and FR43 and DEC-21 keep gestures on for a mouse, a trackpad and a pen. Attach for every pointer with FR43's named exceptions, keep FR24's fine-pointer budget, and update the gestures README to match.
| * past the ends, but held on the nearest enabled tab while the finger is | ||
| * over a disabled one, which shows no drag affordance (AST-085 FR6). | ||
| */ | ||
| const chaseTarget = (x: number, centers: number[]) => { |
There was a problem hiding this comment.
family:action-groups brings a tab bar in by its membership rule, and its FR2 says nothing is highlighted over a disabled action. Parking the lens on the nearest enabled tab lights that tab even though a lift here chooses nothing; one option is to drop the lens back, unlifted, to the selected tab while the finger is over a disabled one.
| // The app's answer to this lift, as rendered now: the tab the finger | ||
| // chose is the one under it at the lift, whatever renders after. | ||
| const deliver = onLiftRef.current; | ||
| const nearest = nearestIndex(press.lastX, press.centers); |
There was a problem hiding this comment.
The lift reads only the finger's x, and the recognizer's movement is unlimited once it begins, so a finger that slides off the bar still commits a tab. family:action-groups FR3 says a press that lifts outside the group acts on nothing; the browser test "a drag that leaves the bar upward still commits where it lifts" pins the opposite.
| * tab can, in the same commit, activate the field and focus it, which is | ||
| * what raises the keyboard on iOS. Active, its glass widens to span the | ||
| * screen but for the field's cancel button, in the bar's row, where a | ||
| * phone's keyboard can cover it. |
There was a problem hiding this comment.
spec:AST-099 FR1 and FR3 require tab bar search to position from the shared on-screen keyboard height. Nothing in the TabBar reads it, and TabBarSearchContext is provided but has no consumer.
The Effect that ends a press when the recognizer turns off, and the one that ends it when the tab list changes under a finger, now say what they synchronize, as the selection Effect does.
While the bar is collapsed its tabs are inert, so focus never lands on a tab: keyboard focus reaches the circle, whose activation expands the bar. The prop doc, the component doc and the hook said focus on a tab expands it.
…tree (AST-085 FR5) Reads Chromium's accessibility tree: the disabled tab keeps its name and is announced disabled on the tab itself; no other tab is.
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved, and it also needs changes. No current spec states the lab TabBar's own presentation (the arrow keys skipping a disabled tab, the collapsed bar as one circle button, and the motion roles its springs would need), so an engineering owner provides or identifies that spec and records the decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner. The disabled tab itself follows AST-085 on every selection path, and the covered search circle leaving the tab order is a sound fix.
- The gesture host attaches recognizers only under a coarse pointer, but AST-094 FR19 and FR43 require gestures for every pointer.
- A tab bar is a
family:action-groupsmember, so its lens should come from the shared action-group tracker, light nothing over a disabled tab, act on nothing when a finger lifts off the bar, and work with every pointer. - AST-099 FR1 and FR3 require tab bar search to position from the on-screen keyboard height, and nothing in the TabBar reads it.
- Land or retarget onto the stacked predecessors so this diff is its own 460-line layer instead of about 36,700 changed lines, move the
astryxStylexfix, the unused press-paint exports and the host's unusedactionGroupoption to their own pull requests, and add an accessibility-tree check for the disabled tab (AST-085 FR5).
[Automated review]
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved, and it also needs changes. No current spec states the lab TabBar's own presentation (the arrow keys skipping a disabled tab, the collapsed bar as one circle button, and the motion roles its springs would need), so an engineering owner provides or identifies that spec and records the decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner. The disabled tab follows AST-085 on every selection path, and the new accessibility-tree test closes the earlier FR5 evidence gap.
- The gesture host attaches recognizers only under a coarse pointer, but AST-094 FR19 and FR43 require gestures for every pointer.
- A tab bar is a
family:action-groupsmember, so its lens should come from the shared action-group tracker, light nothing over a disabled tab, act on nothing when a finger lifts off the bar, and work with every pointer. - AST-099 FR1 and FR3 require tab bar search to position from the on-screen keyboard height, and nothing in the TabBar reads it.
- Land or retarget onto the stacked predecessors so this diff is its own 478-line layer instead of about 36,700 changed lines, and move the
astryxStylexfix, the unused press-paint exports and the host's unusedactionGroupoption to their own pull requests.
[Automated review]
Depends on #8192.
Review only this PR's change: vjeux/astryx@bc3f58b...9efd4fd
User need
Part of matching Astryx's touch components to iOS 26, so apps built with it feel native on phones. Apps sometimes need a tab that can't be used yet; it must look disabled and stay inert under every input, even a finger dragging the lens across it. This adds
isDisabled.Problem and solution fit
isDisableddims it; a tap does nothing; the arrow keys skip it; a lift over it chooses nothing.spec:AST-085FR6): while a finger drags over it, the lens waits on the nearest enabled tab and the disabled tab keeps its disabled look.Current specification
spec:AST-085FR6;spec:AST-012FR9 and DEC-6;architecture:public-component-apiINV17. An engineering owner decides (no record governs it): a lift never commits a disabled tab, and the tab reportsaria-disabled.Public delta and caller burden
New
isDisabled?: booleanonTabBarItem; nothing changes for other callers.Size, gzip against #8192's head: TabBar's import 63.5 → 63.7 KB JavaScript, 1,955 → 1,968 B CSS.
Design and alternatives
Evidence
iOS 26.2 simulator, before (#8192: a tap selects Browse) and after (Browse ignores it; a drag holds the lens on Library); then Android 15 Chrome.
Scope
Stack: #8076 → … → #8320 → #8129 → … → #8192 → this PR.
Testing
Try it:
pnpm storybook, Lab › TabBar › Disabled Tab (Browse is disabled), on a phone or Chrome's device mode.Browser tests: a tap or lift on a disabled tab chooses nothing, by finger or mouse; a drag over it holds the lens on the nearest enabled tab; the minimized search circle stays tappable and announced.
Passing:
pnpm test:interaction TabBar,pnpm vitest run packages/lab/src/TabBar,pnpm typecheck, lint.