Repository navigation
Conversation
…l, straight or diagonal, and not before spec:AST-094 FR20's verification names a finger moved 9 px and 10 px straight, and (7, 7) and (8, 8) diagonally: a scroll above the touch takes it only once the finger has travelled 10 px from where it landed. The host already measures that distance; these cases pin the boundary.
…g running Landing a waiting Reduce Motion move on the node just detached rebuilt every channel the landing touched there, so an axis still moving (a coast on y while x waited in a dip) was baked onto the detached node again and promoted it, leaving an animation, timers and will-change behind. After the landing, the unmount now cancels what runs, clears the retire timers and demotes, before the target goes back to none. The test fails on the previous head.
…seudo-element support
The README's busy-main-thread paragraph and busyWindowProof's JSDoc said an undelivered frame is never a miss; when fewer than minJudgedFrames frames were delivered in the judged part, its span counts every frame. One clause in each says so.
…ose finds it The unmount kept the node of the first attach(null) in the task, so after attach(null), attach(next), attach(null) it landed a waiting Reduce Motion move on the node already replaced, and next stayed at its dip's opacity. A dispose right after attach(null) landed on no element, leaving the detached node at opacity 0. The latest detached node is now kept while its unmount is pending; the unmount and dispose both land there. Two tests fail on the previous head.
…that Effect The isEnabled sync's silence covered recognizer listeners but not usePressTracker: a press-tracked control inside an element whose double tap a rerender turns off heard touchUpInside (and its un-highlight) from that layout Effect (react-component-runtime INV2). Silencing it would leave the control highlighted, so the tracker's callbacks that arrive during a sync run in a microtask just after it, in order: the press still ends and un-highlights, outside the Effect. Tests, failing before (the events arrived inside the Effect): a press waiting on an ancestor double tap, alone and with a single tap waiting on it, reports nothing from the Effect that turns the double tap off, then touchUpInside and the un-highlight just after. Co-authored-by: Christopher Chedeau <vjeuxx@gmail.com>
…ile it ran A page opened after startCompositorTrace and closed before stop() was still credited: its frames are in the browser-wide record, and neither check saw it. The record now watches for new pages from start to stop, in the page's own context and through the browser's target discovery in every context, and stop() throws if one opened. Negative controls: a page opened and closed mid-record, and one in another context, both make stop() refuse; alone, it records.
…rns to joins that dip Under Reduce Motion a call that names an opacity while an earlier dip's move still waits to land took the dip branch. So a call naming the opacity the dip already returns to, with no travel of its own, opened a second dip from where the first had got to: mid fade out the element faded out twice, and in the dip's own task the browser got a second, identical fade. A swipe row's release does exactly that: its move's layer plays the travel as a dip, then its state layer lands opacity 1 on the same element in the same task. Such a call now joins the waiting dip: the planner returns joins, the fade goes on as it was, the call takes the landing over and settles when the dip ends, and the call it replaces lands with it, each value keeping the call whose move it is. A call that names travel, or another opacity, plans as before. Four tests (the planner's, mid dip, in the dip's task, and a release played then landed) fail on the previous code.
@eslint-react/naming-convention-ref-name: the test component added in 07b3383 held its refs as outer and inner, two lint errors that failed CI's ESLint step. Renamed outerRef and innerRef; no other change.
Inside a trace, waitForAnimation and watch.started() read the element through handles, which find no element rather than wait for one, so a wait on an element the page removed rejected with "no animation started on the element" instead of "the element is not in the document", unlike the untraced path. At its deadline, a traced wait with no element now rejects as missing. Traced twin of the missing-element self-test; it fails on the previous code. Co-authored-by: Christopher Chedeau <vjeuxx@gmail.com>
…med or not The planner's comment on the cross-fade's length said it is not a theme role and no theme lengthens it. Under spec:AST-094 DEC-11 no motion role is themeable: the fade's length is no role at all, and nothing lengthens it.
A promotion keeps the stylesheet's will-change reasons beside its own, and read them with getComputedStyle as it started: in a drag's first move, that forces a style recalculation inside the input handler. The stylesheet's value is now read in a task of its own after the element is attached, and again after each demotion, so a promotion uses what was read. One that comes before that read (an element attached in this task that moves at once) still reads it then. A test that counts style reads in the promoting task fails on the previous code; one for the element that moves at once passes on both.
…orts after that Effect react-component-runtime INV2 keeps caller callbacks out of Effects, and the isEnabled sync and a replaced node's detach did it by silencing every listener for the arena pass they start. A single tap waiting on a double tap recognizes in that pass when the double tap is turned off or its node replaced, so its caller never heard the tap. The hook cases expect that caller to hear it once, just after the Effect, reading the recognized state; the arena case expects GestureArena.deferResolution to fail the stopped recognizer at once and resolve the recognition waiting on it in a pass a microtask later. Fail on this head.
…aims an axis only in its edge zone; the promotion's style read in its own task; the planner's DEC-11 line) into the presented start
The isEnabled sync and a replaced node's detach silenced every listener for the arena pass they start (react-component-runtime INV2), so a single tap waiting on a double tap they stopped recognized in that pass and was never reported. Delaying the listener call alone would hand it a recognizer the arena has already reset to possible. GestureArena.deferResolution(body) runs code outside input that stops recognizers without resolving what the stops unblock (the recognitions waiting on them, held touches, resets); a pass a microtask later, at the last event's time, resolves it, or the next input does first. Both hook syncs run inside it, reaching the arena through recognizerInternals: the stopped recognizer's own cancel stays silent, and a recognizer that required it to fail recognizes outside the Effect, where its listener reads the recognized state. The README and the isEnabled option say so.
…rred unmount runs It read will-change right after attach(null), before the unmount's microtask, so it passed while that microtask could still promote the element and leave timers behind. It now awaits the microtask, then checks will-change and that no timer is left. It fails on meta#8521's earlier head (97436b2), before the unmount cleared what the landing rebuilt.
…pseudo-element support
… it is core's one track-across-items loop An export-lock test proves neither the hooks entry point nor the package exports reach the tracker. The header records that it is core's one track-across-items loop, that useMenuPress's copy moves into it next, and that nothing drives it until its adopters land. Co-authored-by: Christopher Chedeau <vjeux@users.noreply.github.com>
…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.
vjeux
marked this pull request as draft
October 29, 2026 22:38
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Changes requested. Routing the tracker through paintPress is the right direction, but against main this pull request now carries all of #8360 (with #8076 inside it), about 27,200 changed lines against its own 91, and dispose can still end a fade the tracker did not start. Please land #8360 first and merge main so the diff shows only the three-file tracker change, and make dispose finish only the tracker's own running fades, with a test for that sequence.
actionGroupTracker.ts:430-437never forgets an action once the writer ends its fade, sodisposealso removes a fade another painter starts on that action later.pressFeedback.ts:204-211and.changeset/gesture-press-tracking.mdstill say the tracker writes its own presses, which this change makes untrue.
[Automated review]
Comment on lines
+207
to
+209
| * paintPress, so a fade's clock and the attribute never drift apart (the | ||
| * action-group tracker, hooks/actionGroupTracker.ts, still writes its groups' | ||
| * presses itself). Any write ends a fade paintPress left running there. |
There was a problem hiding this comment.
With this pull request's tracker change, this parenthetical is no longer true: actionGroupTracker.ts paints on, none and fading through paintPress (:246-268). Could it name the tracker as one of the paintPress painters instead?
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [chore] Internal: UIControl press tracking with control and cell profiles and the gesture hooks. `paintPress` in `utils/pressFeedback.ts` writes `data-astryx-press` for every press it tracks; the action-group tracker writes its groups' presses itself. Not exported from the package entry point. |
There was a problem hiding this comment.
This says the action-group tracker writes its groups' presses itself, while .changeset/action-group-tracker-one-writer.md says it paints through paintPress. Released together, the two entries would contradict each other; could this clause go or be reworded?
…ning fade (red) The tracker remembers each action it left fading and dispose ends those fades. It never forgets an action once that fade is over, so dispose also ends a fade another painter started on the action afterwards: after the tracker's fade ran out, or after another painter replaced it. Both cases fail here.
…started that are still running paintPress takes an onFadeEnd for a fading paint. The writer calls it once, when that fade stops being the element's paint: it ran out on its own clock, or a later write replaced it. The tracker passes one that forgets the action, so dispose ends only its own running fades and leaves another painter's alone. The writer's comment and the press-tracking changeset no longer say the tracker writes its own presses: it paints through paintPress. The tracker's changeset and its dispose doc say what dispose now ends.
There was a problem hiding this comment.
Changes requested. The dispose fix is sound: the writer now tells the tracker when its fade ends or is replaced, so dispose finishes only the tracker's own running fades, and the two new cases cover both sequences. What still blocks is scope: against main this pull request carries all of #8360 (with #8076 inside it), about 27,200 changed lines against its own 164, in a copy that is already four commits behind #8360's branch. Please land #8360 first and merge main so the diff shows only the five-file tracker and writer change, and bring the description's review link and evidence up to date.
packages/core/src/gestures/README.md:216-219still says the tracker writes its groups' presses itself; it needs the same fix as the writer comment and changeset.
[Automated review]
Comment on lines
+218
to
+219
| the action-group tracker (`hooks/actionGroupTracker.ts`) writes its groups' | ||
| presses itself. `paintPress` owns the release timer and writes |
There was a problem hiding this comment.
This still says the action-group tracker writes its groups' presses itself, but at this head it paints on, none and fading through paintPress (packages/core/src/hooks/actionGroupTracker.ts:249-275), and this pull request already corrects the same claim in the writer's comment and drops it from .changeset/gesture-press-tracking.md. Could this sentence name the tracker as a paintPress painter too?
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #8360, which carries #8076. Review only this PR's change: vjeux/astryx@045f666...30e0d10
Maintainer impact
Two pieces of code paint a button's pressed look, and they fight. The document press controller (#8076) paints every Button's press through
paintPress, the one function meant to writedata-astryx-press. The action-group tracker merged in #8346 writes that attribute itself, on its own fade timers. Once a group of buttons adopts the tracker (AlertDialog, ButtonGroup and menus are next), the controller's fade can cut the tracker's short, and the tracker can wipe aheldpaint it never wrote. No component drives the tracker yet, so nobody sees this; it is fixed before the first one does.What led to it: a review of #8346 after it was approved, so the fix comes as this follow-up.
Intended invariant
paintPressis the one writer of the press attribute: a new write ends any fade another painter left running, a fade ends on its own writer's clock, and aheldpaint stays with its owner.Change
The tracker paints
on,noneandfadingthroughpaintPress. It remembers an action only while the fade it started there still runs:paintPresstakes anonFadeEnd, which the writer calls when that fade runs out or a later paint replaces it, sodisposefinishes only the tracker's own running fades. The writer's comment and the press-tracking changeset no longer say the tracker writes its own presses.Options considered:
Evidence
heldaction loses its paint after a press. Two new tests show both and fail on main.disposeends only the tracker's own running fade: two more tests, another painter's fade after the tracker's ran out and one that replaced it, failed on this PR's previous head.Scope
Testing
pnpm vitest run packages/core/src/hooks/actionGroupTracker.test.ts: the four new tests pass here; two fail on main and the twodisposecases on the previous head.pressableCoverage.test.ts, that test passes here and flags main's tracker, so this should merge before them.Also run: build, typecheck, lint, and the hooks, utils, gestures, Button and AlertDialog suites.
Stack (merge in this order): #8360 (which carries #8076) → this PR → #8125 and #8228.