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.
|
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approval is on hold for an owner decision: draft spec:AST-094 has no claim that states presented hit testing, so an engineering owner needs to provide or identify the governing spec for it and settle the record's conflicts with this branch (theme-tunable touch motion against its FR4 and DEC-1, scrollHandoff against its FR14, and its proposed amendment to AST-025 FR14). Any engineering owner listed in .github/ENGOWNERS, the author included if listed, records that decision by commenting /approve-spec <full head SHA> on a head whose record states it. Whatever that decision, three changes are needed:
- Land or retarget onto the predecessor stack so this pull request carries only its own 1,069-line commit instead of 29,253 authored lines.
- On iOS, a drag that starts on a retargeted contact has no cancelable
touchmovelistener Safari honors (packages/core/src/gestures/GestureHost.ts:753, measured in the branch's ownpackages/core/src/gestures/README.md), so keep a document-level listener while something moves or limit retargeting to taps. .changeset/touch-presentation.mdsays an iPad mini in portrait keeps the popover although the old query gave it the bottom sheet, and it ships this change to releasedpresentation="adaptive"behavior as a patch[feat]with no compatibility classification or migration (spec:AST-017FR1, FR3).
[Automated review]
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 |
8fe15df to
d46130e
Compare
github-actions
Bot
added
the
needs:design-review
d46130e to
e4684e7
Compare
e4684e7 to
5106380
Compare
5106380 to
1f5f85d
Compare
There was a problem hiding this comment.
Approval is on hold for an owner decision: draft spec:AST-094 has no claim that states where a touch on a moving element lands, so an engineering owner needs to provide or identify the governing spec for presented hit testing, and settle the record's conflict with the branch's theme-tunable motion roles (its FR4 and DEC-1). Any engineering owner listed in .github/ENGOWNERS, the author included if listed, records that decision by commenting /approve-spec <full head SHA> on a revision whose record states it. Whatever that decision, these changes are needed:
- Land or retarget onto the predecessor stack so this pull request carries only its own 1,069-line commit instead of 34,869 authored lines.
- In iOS Safari a drag that starts on a retargeted contact has no cancelable
touchmovelistener Safari honors once the pan claims (packages/core/src/gestures/GestureHost.ts:747and:1167-1171, with the README's own measurement atpackages/core/src/gestures/README.md:488-490), so keep a document-level listener while something moves or limit retargeting to taps. - The selection lock added to the stable press-feedback controller (
packages/core/src/utils/pressFeedback.ts:306) changes released components' touch behavior, so it needs its own Changeset underspec:AST-017FR1 to FR8 rather than[experimental](FR22), or should stay in the experimental gesture host. packages/cli/assets/theme.template.ts:362documents aplatformadaptation axis thatdefineThemenow rejects, and theVelocityStrategyrelease note, thespec:AST-100and AST-094 OQ4 citations and two untagged experimental constants need correcting.
[Automated review]
| this.touchIds.set(touch.identifier, id); | ||
| this.lockSelection(id, recognizers, consumerElement, target); | ||
| // The finger's events keep going to what the engine hit. | ||
| this.watchTarget( |
There was a problem hiding this comment.
On iOS, when presentedTarget retargets a touch from the scrim to a moving sheet, this blocking listener lands on the engine's target during touchstart, which README.md:488-490 records Safari ignoring for that touch, and the sheet's own non-passive listener (:747) is off the touch's event path. Without a page hold, a pan that claims a retargeted drag cannot cancel a move Safari honors. Consider a non-passive document-level touchmove listener installed while presentation.ts reports a mover, or limiting retargeting to taps.
| @@ -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 now applies to every touch or pen press on released usePressFeedback surfaces (Button, Link, Item and others), turning off text selection and the iOS callout while the finger is held. .changeset/touch-selection-lock.md files it as [experimental], but spec:AST-017 FR22 keeps stable runtime behavior out of that category, so it needs its own Changeset under FR1 to FR8, or should stay in the experimental gesture host.
| * `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.
ThemeAdaptationCondition no longer has a platform axis, and defineTheme throws …platform is not supported. for a rule that follows this line, so the platform clause should go.
| '@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.
VelocityStrategy is no longer exported: .changeset/gesture-recognizer-fixes.md removes it and packages/core/src/gestures/experimental.ts has no such export, so this list should drop it.
1f5f85d to
18623cc
Compare
There was a problem hiding this comment.
Approval is on hold for an owner decision: draft spec:AST-094 has no claim that states where a touch on a moving element lands, so an engineering owner needs to provide or identify the governing spec for presented hit testing and settle the record's conflict with the branch's theme-tunable motion roles (its FR4 and DEC-1). Any engineering owner listed in .github/ENGOWNERS, the author included if listed, records that decision by commenting /approve-spec <full head SHA> on a revision whose record states it. Whatever that decision, these changes are needed:
- Land or retarget onto the predecessor stack so this pull request carries only its own 1,070-line commit instead of 34,986 authored lines.
- In iOS Safari a drag that starts on a retargeted contact has no cancelable
touchmovelistener Safari honors once the pan claims (packages/core/src/gestures/GestureHost.ts:746-750and:1050-1054, with the README's own measurement atpackages/core/src/gestures/README.md:491-493), so keep a document-level listener while something moves or limit retargeting to taps. - The press-feedback selection lock (
packages/core/src/utils/pressFeedback.ts:306) changes released components as a[fix]with no current authority (spec:AST-017FR33) and also locks pens, so it needs an owner decision, touch-only scope or fine-pointer evidence (FR59), and a[feat]Changeset. - Pointer-path retargeting also reaches a mouse, trackpad or pen on iPad without fine-pointer evidence (FR59), the theme template documents a
platformaxisdefineThemerejects, and theVelocityStrategyrelease note, thespec:AST-100and AST-094 OQ4 citations and two untagged experimental constants need correcting.
[Automated review]
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [fix] Under a finger or pen, holding a control or a cell that shows the touch press (the press feedback surfaces) no longer starts text selection or the iOS callout, as on UIKit controls. Selection and the callout come back when the finger lifts. Text fields keep their selection, and a mouse keeps desktop selection. |
There was a problem hiding this comment.
[fix] needs pre-existing current authority that the released behavior violated (spec:AST-017 FR33: "Without pre-existing authority, the proposal is a new contract decision for the direct owner, not a fix"), and no current claim requires press-feedback surfaces to block selection or the callout. The lock also applies to pens, since the controller skips only mouse (packages/core/src/utils/pressFeedback.ts:270), which current FR59 allows only with fine-pointer before-and-after evidence. Once an owner decides the behavior, a touch-only (or pen-evidenced) [feat] fits.
| if (event.pointerType === 'mouse' && event.button !== 0) { | ||
| return; | ||
| } | ||
| const target = this.presentedTarget( |
There was a problem hiding this comment.
This runs for mouse and pen presses too, so in iPadOS Safari a trackpad click or a Pencil press on a moving element is retargeted and its click replaced (:1652-1664). spec:AST-017 FR59 asks for fine-pointer before-and-after evidence when touch work reaches those pointers; otherwise keep the engine's target for mouse and pen here.
18623cc to
2ed296e
Compare
…xposes no ontouchstart is taken once Chromium fixes ontouchstart when the page is created, so turning touch emulation on later sends Touch Events without it: the host reads Pointer Events for the finger and must not read its Touch Events too. A one-finger long press fails here, the finger tracked twice.
…from their pointer events install() reads a finger from its pointer events when the window has no ontouchstart, but the four touch handlers still took the Touch Events a browser sends anyway (Chromium after touch emulation turns on), tracking the finger twice, so a one-finger long press never recognized. Each touch handler now returns while usesTouchEvents is false, after noting the fingers down, as install()'s comment promised.
…ter events) into meta#8320
…ter events) into meta#8293
There was a problem hiding this comment.
This review is waiting on an owner decision: current spec:AST-094 covers moving content only for a catch (FR6), so before presented hit testing can be approved an engineering owner has to update it to say where a tap or an iPad mouse, trackpad or Pencil press on moving content lands, whether a retargeted tap may activate through a script click although FR11 keeps activation on the browser's click, and whether a document-level blocking touchmove listener is acceptable although FR19 keeps it on the recognizer's element; your proposed FR14 sentence covers only the first. Any engineering owner listed in .github/ENGOWNERS, you included, records that decision by landing the amendment on main, or by commenting /approve-spec <full head SHA> once this pull request carries it. These changes are needed either way:
- Land the predecessors first and drop the #8340 merge, so this pull request shows its own change instead of 26,765 lines, and move out the
astryxStylexfix and the harness additions as announced. - Make a retargeted tap act once when only watchers are attached; today nothing cancels or swallows the engine's click (
packages/core/src/gestures/GestureHost.ts:1930-1939). - Let a drag retargeted onto a claiming recognizer outside every moving element claim (
packages/core/src/gestures/GestureHost.ts:1108-1152). - Add a removal condition for the
-webkit-touch-calloutgate, plus real-device iOS Safari, real-touch drag and fine-pointer evidence, and correct the two notes that still say the inline style holds the end.
[Automated review]
…xperimental touch exports The motion README's Files table is the union: main's rows, with meta#8663's resolveSnapPoint.ts and selectPage.ts, plus this branch's, in main's order. # Conflicts: # packages/core/src/motion/README.md
…on/README.md) into facebook#8309
…; this pull request's presentation.ts rows kept beside them) into meta#8293
There was a problem hiding this comment.
This pull request is waiting on an owner decision: current spec:AST-094 covers moving content only for a catch (FR6), so before presented hit testing can be approved an engineering owner has to settle where a tap or an iPad mouse, trackpad or Pencil press on moving content lands, whether a retargeted tap may activate through a script click although FR11 keeps activation on the browser's click, and whether a document-level blocking touchmove is acceptable although FR19 keeps it on the recognizer's element. Any engineering owner listed in .github/ENGOWNERS, you included, records that decision by landing the AST-094 amendment on main, or by adding it to this pull request and commenting /approve-spec <full head SHA>. These changes are needed either way:
- Land the predecessors first and drop the #8340 merge, so this pull request shows its own change instead of 26,815 lines, and move out the
astryxStylexfix and the harness additions as announced. - Make a retargeted tap act once when no claiming recognizer is attached (
packages/core/src/gestures/GestureHost.ts:1936-1944). - Let a drag retargeted onto a claiming pan outside every moving element claim (
packages/core/src/gestures/GestureHost.ts:1118-1152). - Add a removal condition for the
-webkit-touch-calloutgate, real-device iOS Safari, real-touch drag and fine-pointer evidence, and correct the two notes that say the inline style holds the end.
[Automated review]
| // A tap sent to what is drawn: the engine's click would hit the layout | ||
| // position, so it is cancelled and the tap clicks what it touched. | ||
| for (const end of retargetedEnds) { | ||
| if (this.clickRetargetedTap(end.landed, end, dispositions.get(end.id))) { |
There was a problem hiding this comment.
With no claiming recognizer or press tracker attached anywhere, hasClaimer() is false: the document and target touchend listeners are passive and the window click swallower is not installed (:1329-1359, :2094-2098). This click is then followed by the engine's own click, so the tap activates twice. Retarget only contacts a claiming participant takes, or keep a cancelable touchend and the swallower installed while a retargeted contact is down, with a watcher-only test.
| const needed = | ||
| isWatching && | ||
| presentedElements().some(mover => | ||
| this.hasClaimingRecognizerAround(mover), | ||
| ); |
There was a problem hiding this comment.
This covers a claiming recognizer in or around a mover only. A contact retargeted onto a claiming pan outside every mover (:682-686) keeps only the listener watchTarget adds during touchstart, which AST-094 FR19 says “would hand diagonal drags to the scroll” and the README says Safari does not honour, so that pan cannot claim. Keep the document listener while any mover moves and a claiming recognizer is attached, or count claimers whose element intersects a mover's start box.
| * the compositor where the animation STARTED: it keeps the transform it | ||
| * resolved when the animation went to the compositor, so event targets, | ||
| * `elementFromPoint` and `getBoundingClientRect` stay there for the whole | ||
| * curve, while the inline style already holds the end and the computed |
There was a problem hiding this comment.
At this head the animator writes the curve's start inline while it runs (motion/animator.ts:45-47), so “the inline style already holds the end” states the opposite of the code; the same clause is in gestures/README.md:568-569.
| * utils/touchPresentation.ts, which this module cannot import: it brings | ||
| * React). | ||
| */ | ||
| function isIosWebKit( |
There was a problem hiding this comment.
spec:AST-013 FR6 allows a narrow engine workaround only with a review or removal condition; none is stated here, in motion/presentation.ts or in the README section, and utils/touchPresentation.ts:88-90 reserves this check “For a style iOS WebKit requires, never a behaviour”.
… a mouse press At the document, an event from inside an open shadow root is retargeted to the shadow host, and so is a touch's target, so the host looked for participants from the shadow host and found none inside the root: the browser then sent its own mousedown and click. Both cases, a finger and a mouse, attach a tap to an element in the shadow root. Fail until the host resolves targets through the composed path.
…composed path Inside an open shadow root the document's listeners see the shadow host, in event.target and in a touch's target alike, so a recognizer on an element in the root never got its finger, and nothing claimed it. landedOn takes the composed path's first element for the event's own target and for a touch whose target is the event's (another finger keeps its own): a touch's start, a pointer's press and its pairing, the last touch a scroll reads, a cancelled pointer's touch and hover.
…he host resolves targets through the composed path) into meta#8320
There was a problem hiding this comment.
This pull request is on hold for an engineering owner's decision: current spec:AST-094 covers moving content only for a catch (FR6), so an owner needs to amend it to state where a tap or an iPad mouse, trackpad or Pencil press on moving content lands, whether a retargeted tap may activate through a script click although FR11 keeps activation on the browser's click, and whether a document-level blocking touchmove is acceptable although FR19 keeps it on the recognizer's element. Any engineering owner listed in .github/ENGOWNERS, you included, records that decision by landing the amendment on main, or by adding it here and commenting /approve-spec <full head SHA> on the pull request. These changes are needed either way:
- Land the predecessors first and drop the #8340 merge, so this pull request carries its own change instead of 26,870 authored lines.
presentedTargethit-tests with the document'selementFromPoint, which returns the shadow host, so on iOS a control inside an open shadow root on moving content never activates (packages/core/src/gestures/GestureHost.ts:695-703).- With only watchers attached a retargeted tap activates twice (
GestureHost.ts:1963-1967), and a drag retargeted onto a claiming pan outside every moving element cannot claim (GestureHost.ts:1135-1139). - Add a review or removal condition for the
-webkit-touch-calloutgate, plus real-device iOS Safari, real-touch drag and fine-pointer evidence.
[Automated review]
| // drawn now; the hit test below flushes them. The engine then gets | ||
| // z-order, pointer-events and clipping right, which no box math would. | ||
| resolvePresented(movers); | ||
| const hit = this.doc.elementFromPoint(x, y); |
There was a problem hiding this comment.
document.elementFromPoint returns the shadow host for anything inside an open shadow root, and mover.contains does not cross the shadow boundary, so on iOS a contact on moving content inside a shadow root is retargeted to the host: recognizers inside it take no part and the tap's click is dispatched on the host, never reaching the control inside, while the engine's click is cancelled. That undoes the composed-path handling landedOn adds for moving content. Descend through shadowRoot.elementFromPoint from this hit and compare containment across shadow roots; a shadow-root case in presentedHitTesting.test.ts would cover it.
| if (cancelsClick) { | ||
| if (event.cancelable) { | ||
| event.preventDefault(); | ||
| } | ||
| this.armSwallower(); |
There was a problem hiding this comment.
With only watchers attached, this touchend listener is passive (syncClaimingListeners, lines 1346-1376) and the click swallower is not installed, so after clickRetargetedTap clicks the drawn element the preventDefault here is ignored and the engine's click still lands where the animation started: two activations on two elements. Retarget only while the click can be cancelled, or keep the swallower installed while a retargeted contact is in flight.
| const needed = | ||
| isWatching && | ||
| presentedElements().some(mover => | ||
| this.hasClaimingRecognizerAround(mover), | ||
| ); |
There was a problem hiding this comment.
This blocks only while a claiming recognizer lives in or around a mover. A contact whose engine target is inside a mover but whose drawn target is a claiming pan outside every mover (a swipeable row a sliding toast is leaving) gets no touchmove listener Safari honours, so the pan begins but cannot claim (spec:AST-094 FR19).
| function isIosWebKit( | ||
| view: (Window & {CSS?: Partial<typeof CSS>}) | null, | ||
| ): boolean { | ||
| return view?.CSS?.supports?.('-webkit-touch-callout', 'none') === true; | ||
| } |
There was a problem hiding this comment.
spec:AST-013 FR6 allows a narrow engine workaround only "with a regression fixture and a review or removal condition". No condition sits here, in motion/presentation.ts or in the README section, and utils/touchPresentation.ts documents this check for styles iOS WebKit requires, never a behaviour.
| * the compositor where the animation STARTED: it keeps the transform it | ||
| * resolved when the animation went to the compositor, so event targets, | ||
| * `elementFromPoint` and `getBoundingClientRect` stay there for the whole | ||
| * curve, while the inline style already holds the end and the computed |
There was a problem hiding this comment.
…adow root; a claimed touch's moves are cancelled where fingers come from pointer events With targets from the composed path, a finger inside an open shadow root sits below the scroller only along the flat tree, which Node.contains does not follow: a scroll under it did not take it, and its flick did not arm the scroll brake. And where the host reads fingers from pointer events (inputMode 'auto' with no ontouchstart), the blocking touchmove found no finger for a claimed pan's touch, so its moves went to the page. Three cases fail until the host compares along the flat tree and finds that finger; a fourth pins a finger scroll inside a shadow root.
… tree; a claimed touch finds its pointer finger wherever fingers come from pointer events containsAlongFlatTree walks parentAcrossShadow, so a finger inside an open shadow root, now that targets come from the composed path, counts as under a scroller outside it: a scroll there takes it, its flick arms the scroll brake, and a touch there brakes. cancelIfClaimed matches a touch to its pointer finger whenever the host reads fingers from pointer events, not only under inputMode 'pointer-events', so a claimed pan's moves are cancelled where a browser that exposes no ontouchstart still sends Touch Events.
… flat tree, and a claimed touch finds its pointer finger wherever fingers come from pointer events) into meta#8320
…r along the flat tree, and a claimed touch finds its pointer finger wherever fingers come from pointer events) into meta#8293
There was a problem hiding this comment.
This pull request is on hold for an engineering owner's decision. Current spec:AST-094 covers moving content only for a catch (FR6), so an owner needs to amend it to say three things:
- where a tap, or an iPad mouse, trackpad or Pencil press, on moving content lands;
- whether a retargeted tap may activate through a script click, although FR11 keeps activation on the browser's click;
- whether a document-level blocking
touchmoveis acceptable, although FR19 keeps that listener on the recognizer's element.
Any engineering owner listed in .github/ENGOWNERS, you included, records that decision by landing the amendment on main, or by adding it here and commenting /approve-spec <full head SHA> on the pull request. These changes are needed either way:
- Land the predecessors first and drop the #8340 merge, so this pull request carries its own change instead of 26,990 authored lines.
- With only watchers attached, a retargeted tap activates twice (
GestureHost.ts:1976-1979), because the touchend listener is passive and the click swallower is not installed. presentedTargethit-tests with the document'selementFromPoint, which returns the shadow host, so a control in the open shadow root of a moving element never activates while the element moves (GestureHost.ts:708-715).- A drag retargeted onto a claiming pan outside every moving element gets no blocking listener and cannot claim (
GestureHost.ts:1167-1182). - Add a review or removal condition for the
-webkit-touch-calloutgate (spec:AST-013FR6) and real-device iOS Safari evidence.
[Automated review]
| cancelsClick = true; | ||
| } | ||
| } | ||
| if (cancelsClick) { |
There was a problem hiding this comment.
With no claiming recognizer or press tracker attached anywhere, this document touchend listener is passive and the window click swallower is removed (syncClaimingListeners, lines 1359-1388). After clickRetargetedTap clicks the drawn element, the preventDefault here is ignored, and the engine's own click still lands where the animation started: two activations on two elements. Retarget only while the click can be cancelled, or keep a cancelable touchend and the swallower installed while a retargeted contact is down, and add a watcher-only test.
| // drawn now; the hit test below flushes them. The engine then gets | ||
| // z-order, pointer-events and clipping right, which no box math would. | ||
| resolvePresented(movers); | ||
| const hit = this.doc.elementFromPoint(x, y); |
There was a problem hiding this comment.
document.elementFromPoint returns the shadow host for anything inside an open shadow root, and mover.contains (line 714) does not cross the boundary. A contact on shadow content of a moving host is therefore retargeted to the host: recognizers inside it get no finger, and the tap's click is dispatched on the host while the engine's click is cancelled. Descend through shadowRoot.elementFromPoint while the hit is a host with an open root, and compare with containsAlongFlatTree (line 344). A shadow-root case in presentedHitTesting.test.ts would cover it.
| } | ||
| for (const [element, registration] of this.registry) { | ||
| if ( | ||
| (mover.contains(element) || element.contains(mover)) && |
There was a problem hiding this comment.
This counts only claiming recognizers in or around a mover. Take a contact whose engine target is a moving element but whose drawn target is a claiming pan outside every mover, such as a swipeable row a sliding toast is leaving. It keeps only the listener watchTarget adds at touchstart, which spec:AST-094 FR19 says "would hand diagonal drags to the scroll", so the pan cannot claim. Keep the document listener while any mover moves and any claiming recognizer is attached, or include claimers whose box meets a mover's start box.
| function isIosWebKit( | ||
| view: (Window & {CSS?: Partial<typeof CSS>}) | null, | ||
| ): boolean { | ||
| return view?.CSS?.supports?.('-webkit-touch-callout', 'none') === true; |
There was a problem hiding this comment.
spec:AST-013 FR6 allows a narrow engine workaround only "with a regression fixture and a review or removal condition". No condition is stated here, in motion/presentation.ts or in the README section, and utils/touchPresentation.ts reserves this check "For a style iOS WebKit requires, never a behaviour".
| * the compositor where the animation STARTED: it keeps the transform it | ||
| * resolved when the animation went to the compositor, so event targets, | ||
| * `elementFromPoint` and `getBoundingClientRect` stay there for the whole | ||
| * curve, while the inline style already holds the end and the computed |
There was a problem hiding this comment.
With the merged start-value write, the animator holds the curve's start inline while it runs (animator.ts lines 45-47), so "the inline style already holds the end" states the opposite. gestures/README.md lines 568-569 repeat it.
| /** | ||
| * Per document or shadow root: the values it has a rule for, their rules' | ||
| * text, and where that text goes (an adopted sheet, or a style element where | ||
| * constructable sheets are missing). Rules are never removed: there are only |
There was a problem hiding this comment.
Because rules are never removed, the adopted sheet or style element stays after the last recognizer detaches, which spec:AST-094 FR24 rules out ("nothing touch-related remains after the last instance unmounts"). Dropping the sheet when the host uninstalls would conform.
|
Closing: carried by #8360 (this head, c1186e4, is in it by hash). The review items:
|
Depends on #8320. Review only this pull request's change: https://github.com/vjeux/astryx/compare/cfaad0342b..c1186e4f63
Why
On an iPhone, a tap on a sheet that is still moving lands where the sheet started. After an upward flick, a tap aimed at the sheet's Done button hits the scrim behind it and closes the sheet; a tap on the spot Done just left presses Done.
What led to it
This came up in the UIKit-parity work on Astryx's touch components, which are meant to feel as they do on iOS. iOS WebKit keeps the transform it resolved when an animation moved to the compositor: hit testing,
elementFromPointandgetBoundingClientRectall stay at the starting position until a style write. Chromium and desktop WebKit hit what is drawn, so the tests passed. UIKit hit-tests an interruptible animation where it is drawn.Options and tradeoffs
Why this choice
The third costs one write per touch, only on the engine that is wrong, and only while something moves. A tap that lands on the drawn element clicks it once: the engine's own click is cancelled and a late duplicate is dropped. Blocking
touchmovestays registered while a claiming element moves, so a drag that starts on the drawn sheet still claims (spec:AST-094FR14, FR19).How to check it
Evidence