[vjeux]

Depends on #8058 (and its predecessors); review the last commit.

Primary intent

Add the first two recognizers on the gesture core: tap and long press, with UIKit's measured thresholds.

User or maintainer impact

Taps, double taps and long presses are re-implemented per component today, with their own slops and timers. A long press can fire late when the main thread is busy, and a single tap can fire alongside a double tap. These recognizers give every component UIKit's numbers. A long press begins at exactly touch-down + 0.5 s, even when the callback runs late.

Problem and solution fit

• Why does it happen? Each component keeps its own timers and slops.
• Why does that hurt? Taps fail or fire twice, and long presses start late or at the wrong distance.
• Why does it matter? These are the commonest gestures on a phone.

Deltas:

• TapGestureRecognizer:
  • taps and fingers;
  • recognized at the lift;
  • fails past its allowable movement (a distance), on extra fingers, a hold past the maximum, or a late or far next tap.
• LongPressGestureRecognizer:
  • the press duration as a deadline on the event clock;
  • the movement tolerance as a distance;
  • taps before the press;
  • a zero duration begins on the touch itself, for selection tracking over a group of actions.
• The arena with these real recognizers: tap against double tap with and without require-to-fail, delegate requirements, delivery and deferred clicks, cancellation before and after a long press began.

Authority

spec:AST-094 (FR15–FR17), proposed; pending owner review. Thresholds come from motion/uikit/gestures.ts with their sources.

Change and evidence

Read from UIKit's recognizers in a reference app on the iOS 26.2 simulator, confirmed with HID touches:

• tap: 45 pt of movement (Euclidean); taps 0.35 s and 45 pt apart; a 1.5 s maximum hold;
• long press: 0.5 s and 10 pt as a distance (a 7, 7 drift begins, 7.2, 7.2 fails).

Mobile Safari, which runs UIKit's tap and double-tap recognizers, agrees:

• a click up to 45 px of travel;
• a double tap up to about 350 ms and 45 px apart.

The tests use explicit timestamps only.

Scope

• This PR has one primary intent.
• Independently removable deltas were removed or split.
• Public text and artifacts contain no internal Meta context.

Testing

• pnpm exec vitest run --project ui packages/core/src/gestures packages/core/src/motion: 184 tests passed.
• tsc --project packages/core/tsconfig.json --noEmit: clean.
• eslint packages/core/src/gestures: clean.
• pnpm check:changesets, node scripts/release/changeset-coverage.mjs pr --base origin/main: clean.
• Size: 7 files, 821 lines added.

Stack (merge in this order): #8052 spec → #8053 constants table → #8058 gesture core → #8059 tap and long press → #8060 pan → #8061 other recognizers → #8054 math → #8055 animator → #8056 animator curves; the gesture DOM host, press tracking and browser proof follow the animator.

[vercel]

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

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Oct 26, 2026 3:51am UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🟢 Reviewed (for maintainers only)	Oct 26, 2026, 4:03 AM UTC

[astracat-bot]

This pull request is on hold for a spec decision: the tap and long-press recognizers, the gesture core and the UIKit constants table rest only on draft spec:AST-094, so an engineering owner needs to approve FR1, FR2, FR12 and FR15–FR17 (approving the record as written also accepts FR4, FR11 and FR14's changes to theme-tokens, user-states and AST-025) by commenting /approve-spec <full head SHA> on this pull request, which the author may do as an engineering owner, or the change waits until #8052 lands the record. Independently of that decision, please address these points:

• A two-finger double tap fails at its second tap because TapGestureRecognizer.ts:93-101 compares the next tap's first finger with the previous tap's last-lift position, so compare centroids (or matching fingers) and add a two-finger double-tap test.
• After a long task, if the arena's own timer runs before a queued touchend, GestureArena.ts:831-836 begins a long press whose finger already lifted, so yield to queued input before running a late deadline and test that order.
• The diff carries 5,065 lines because #8052, #8053 and #8058 ride along, so land them first to make this pull request its own 821-line commit, and rerun the Lint job, which aborted out of memory.

[Automated review]

[astracat-bot]

A two-finger double tap fails here: touches[0] is the next tap's first finger, but firstTapLocation (line 145) is the previous tap's last-lift position, or its centroid when the fingers lift together. The same two-finger tap repeated at the same two points 100 px apart fails at the second tap's first finger. Compare the next tap's centroid once its required fingers are down with the first tap's centroid (or each finger with the nearest first-tap finger), and add a two-finger double-tap test.

[astracat-bot]

After a long task the browser may run this timer task before a queued touchend. advanceTime(Math.max(earliest, this.clock.now())) then runs the long-press deadline first, so a finger that lifted at 300 ms during a 100–900 ms block still begins a press at 500 and ends it at 900 instead of failing at 300. Consider yielding once to queued input before running a late deadline, and add a test whose clock fires the timer before the queued lift.