[vjeux]

Depends on nothing (based on main).

Maintainer impact

A held finger that slides across targets and lifts on one is tracked in several places. Menus (useMenuPress), alerts and action sheets (useActionGroupTracking, #8083), the segmented control (#8127) and the page control's scrub (#8174) each resolve the target under the finger, paint or report it, and activate it. Review asked for one implementation ("a shared tracker"). This adds that tracker as a standalone building block, internal to core. #8110 moves the alert's tracking onto it, and the others stack on it without pulling in menus or alerts.

Intended invariant

• Rects are read once when a press begins (and on remeasure), never per move.
• The default target is the hit test grown by highlightExpansion.
• Disabled targets are skipped; an inert press paints and runs nothing.
• The action runs through its own click() inside the lift's event, keeping the user activation and every click handler.
• The highlight paints with the press attribute and fades for PRESS_FADE_MS at the lift.

Change

hooks/actionGroupTracker.ts adds createActionGroupTracker(getOptions), which returns begin, move, end, cancel, offsetBy, remeasure, dispose, highlighted, beganOn and isTracking. Options:

• roots, itemSelector, highlightExpansion.
• resolveTarget(x, y, targets): the owner picks from the measured rects (a segmented control: the nearest segment along x, and past the ends the end one, so a lift anywhere commits).
• onMove(x, y): every finger position, before it is resolved.
• paintsHighlight: false, plus onHighlightChange(next, previous): for an owner that shows the highlight another way (focus, a dimmed title).
• onActivate (replaces the click), and onActivated(item, cancelled): whether a handler's preventDefault() vetoed the click.
• swallowsNativeClick: the browser's own click for an unclaimed touch is taken once after the lift. Its listeners exist only until that click, the next press or a key. An activation with detail === 0 (a key, assistive technology) always passes (spec:AST-094 FR21).

Evidence

• Before: each component carries its own resolution, paint and activation for a held finger.
• After: 22 jsdom tests drive the tracker directly as a recognizer would. They cover a press that begins while another is tracked, each option, the cancelled click, the one swallowed browser click, an activation with detail === 0 passing it, and the swallower's listener lifetime.

Public delta

None: the tracker is internal to core, with no export from a package entry point (no new public surface without its own spec decision). No product behavior, visual direction or policy changes.

Testing

• pnpm vitest run packages/core/src/hooks/actionGroupTracker.test.ts: 22 pass; the detail === 0 case fails without its change.
• Core typecheck, eslint, prettier, check:changesets, changeset coverage, sync:exports (unchanged), the CLI's experimental-isolation goldens (unchanged).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Oct 26, 2026 11:56pm UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🟢 Reviewed (for maintainers only)	Oct 27, 2026, 12:19 AM UTC

[cixzhang]

/approve-spec 0b92ae3

[astracat-bot]

This is ready to merge as an internal building block: no package path reaches the tracker (a new test enforces that), no component uses it yet, and its click swallower never blocks a detail === 0 activation, as spec:AST-094 FR21 asks. Before #8110 and #8127 start depending on its defaults, four of them deserve a fix or a documented precondition:

• When highlightExpansion exceeds the gap between neighbours, the hit test returns whichever target comes first in the DOM, so a finger just inside the second target can fire the first.
• Targets marked data-astryx-pressable also get data-astryx-press from the document press controller, which wipes the tracker's highlight after a finger leaves its starting target and returns.
• onActivated reports cancelled: false for a vetoed click on a target inside a shadow root, because the check compares event.target, which outside the shadow tree is the host.
• With swallowsNativeClick, a lift that fires nothing (an inert press, a slide off every target, a target disabled mid-press) arms no swallower, so the browser's own click for that touch still goes through.

[Automated review]

[astracat-bot]

For a target inside a shadow root, this window listener sees the host as event.target, so clicked stays null and onActivated gets cancelled: false even when a handler called preventDefault(), while the same target in the light DOM reports true. Menus already render inside shadow roots and the header says their loop is moving here, so identifying the element through event.composedPath() would keep the report right for them.

[astracat-bot]

With swallowsNativeClick, this early return (and the disabled one just below) arms no swallower, so after an inert press, a slide off every target or a target disabled mid-press, the browser's own click for an unclaimed touch can still reach the target the touch began on, against the header's "nothing when there is none". Arming the swallower on every lift of a tracked touch, or documenting that the owner must block that click, would close the gap.

[cixzhang]

Posted by Cindy's agent on her behalf: closed and reopened only to restart this PR's CI on the current workflow after tonight's queue-wide cancel; nothing in the PR changed.