test(core): BottomSheet detents, proven with the interaction harness by vjeux · Pull Request #8423 · meta/astryx

vjeux · 2026-10-25T16:29:45Z

Review only this PR's change: vjeux/astryx@ec8a345...dc418ea

Stacked on #8549 and #8548. Its base includes the main merges offered for #8548 and #8549, pending their author's decision.

Maintainer impact

The interaction harness (#8045) proves its instruments on fixture pages, but component work needs a real component spec to copy, and BottomSheet's detent motion had no frame evidence. Options: keep proving the harness on fixtures only, or write one component spec that uses each instrument (chosen), on the sheet, whose settle exercises them all.

Intended invariant

No product change. On the "Snap points" story, under real touch input, this spec pins:

A slow release settles on the nearest detent.
A 2,000 px/s downward flick dismisses the sheet.
The settle lands on the detent. Its curve, today the theme's 300 ms --ease-standard transition, is recorded, not asserted: it starts a release at rest at about 1,400 px/s, where spec:AST-094 FR38 starts it at the finger's speed.
The settle keeps advancing while the main thread is blocked, with no Layout or Paint per frame.

Awaiting BottomSheet's owner. component:BottomSheet does not state these four outcomes yet. An engineering owner records them in the BottomSheet contract, or decides that this spec stops pinning them.

Change

BottomSheetDetent.interaction.browser.spec.ts: the four outcomes above, plus drag and settle storyboards. Each test names the harness instrument it uses.
The busy-main-thread proof reads where the settle ends from the marker chip the screencast frames track, not from the sheet's top; a check pins that the judged window runs until the marker is within 2 px of its rest.
packages/core gains the harness as a devDependency; the harness README and config name this spec as the one to copy.

Evidence

Before: read from the sheet's top, the judged window ended with the marker 11 px short of its rest (3 of 3 runs), and an upward settle read as a stall that was the reading, not BottomSheet.
After: downward and upward settles advance on every frame through a 700 ms block, in Chromium and WebKit.

Scope

No intended public API, product behavior, visual direction, or policy change.
Product changes discovered during the work were removed or split.
Public text and artifacts contain no internal Meta context.

Testing

How to check: build Storybook, then run pnpm test:interaction BottomSheetDetent; each test names what it proves.

What ran on this head: the detent spec and the harness's own spec pass in Chromium (59, 1 skipped) and WebKit (115, 15 skipped), except one harness self-test that fails on its own in WebKit, fixed by #8535. The root build, typecheck and lint pass.

Adds internal/interaction-harness (@astryxdesign/interaction-harness) and playwright.interaction.config.ts: phone-sized touch projects in Chromium and WebKit for *.interaction.browser.spec.ts specs. Touch scripts are data (tap, drag with hold and rest, flick with an exact release velocity and velocity profiles, hold-then-drag, pinch, rotate, any path, a second finger mid-gesture), played as real engine input: CDP Input.dispatchTouchEvent with scripted timestamps in Chromium, WebKit's own input command in WebKit. The harness's self-test proves the timestamps, a native fling and multi-touch delivery; a pr-interaction CI job runs the proofs against each PR's Storybook build, and a container script runs the WebKit project where host libraries are missing.

… Chromium The Chromium driver sent a lift of one finger of several as a touchMove listing the fingers still down, assuming CDP releases a point a move omits. It does not: the lifted finger stayed down. A touchEnd that lists the lifting fingers releases exactly those while the others keep moving, so the driver sends that, and a self-test lifts one of two fingers and checks the release, the other finger's moves and the touchend's remaining touches. Playwright's WebKit sends that touchend with no remaining touches, which iOS never does. The harness does not work around it: drivers expose partialLifts, and PARTIAL_LIFT_SKIP is the reason a proof cites when it skips; the README lists it with the other engine limits.

… lift profiled flicks at their velocity - pr-interaction now always reports and the `test` join requires its success (AST-030 FR7, FR11), shaped like test-native-swift: a Linux interaction-scope job decides, with the base's scope helper and failing closed, whether the harness, a component, Storybook, internal/a11y-spec, the workflow, package.json or pnpm-lock.yaml changed. Only then do the proofs take a 4-core runner; otherwise, and in merge groups (as with pr-a11y), the job passes without work. - A profiled flick's last move runs at velocity times profile(1), so the finger lifts at the documented velocity, and releaseVelocity reads the last move instead of a 100 ms window mean. - Docs: drop the /math subpath this package does not export yet; scripted timestamps arrive to 0.1 ms; the job comment describes the self-test it runs.

…ed its previous position A sample that repeats a position is not a move: frames that merge() inserts for another finger, where this finger did not move, made the last move look shorter, so a 10 Hz drag merged with a tap read 375 px/s instead of 300 and a 60 Hz drag whose other finger lifted 5 ms before its last move read about 3.6x too fast. The previous sample is now the first one at the previous position, as the page sees it, with a merged case in scripts.test.ts.

Pause every Web Animation, seek it to a time and read the presented transform and opacity, then compare the curve with oracles that share no code with the motion under test: cubic-bezier, the SwiftUI spring (response, dampingFraction, initial velocity), UIScrollView deceleration and UIKit's rubber band. Storyboards photograph seeked animations at t = 0, 16.7, 33.3 ... ms or each step of a scripted touch, and write a PNG contact sheet plus the JSON trace a spec asserts, under the gitignored test-results/interaction-evidence. A timer gate holds a component's own timers while a filmstrip is taken. pnpm storyboards runs the tagged tests.

…sented values An animation that keeps its end value in a run of identical final keyframes (held so a later interruption can read it) reported its whole duration as the curve: storyboards filmed the hold, waitForAnimation's interval reached past the landing, and waitForRest, which also required every animation to leave the running state and read only transform, timed out. The curve now ends where that run starts (HeldAnimation.curveEndMs, waitForAnimation's to, the default storyboard times), and rest is no animation pending or before its curve's end plus the presented transform, translate, rotate, scale and opacity (and ::backdrop opacity) still for 3 frames, whatever the playState. sampleCurve composes translate, rotate and scale with transform, so curves of the individual properties are sampled.

@Storyboard

…film no endless curve, let the page cancel gated callbacks - holdAnimations holds only running document-timeline animations: a finished fill animation keeps its end value, an animation the page paused stays paused (release resumes only what was held), and a scroll-driven one is not seeked. Each held animation keeps its offset from the earliest start, so staggered starts stay staggered. - A sample or storyboard frame at or past an end reports the time it was read at (presentedAt, half a millisecond inside the end), and curveOf reads oracles there. - An animation that repeats forever no longer sets a storyboard's default length (it ran the worker out of memory); with nothing else to film, animationStoryboard asks for times. - The timer gate queues held callbacks by id, so the page's clearTimeout and cancelAnimationFrame still cancel them; a held frame callback gets the time it runs; frames(), waitForRest and touchStoryboard use the real requestAnimationFrame, so they resolve while frozen. - The storyboard self-tests carry the @Storyboard tag that `pnpm storyboards` selects.

…s from the element's own animations, resume endless ones - animationStoryboard's default times run from the earliest start to the latest curve end among the animations that end, each seek at origin + t: beside a spinner that started earlier the animation under test no longer shows its start in every frame, and a second animation that starts later is filmed to its end. - A sample's presentedAt (per channel: transform, opacity) comes from the sampled element's own animations, by keyframe property, not from any animation on the page. - releaseAnimations({finish: true}) resumes an animation that repeats forever instead of finishing it (which throws), and always clears the held set. - The interaction proofs' scope includes packages/themes/*/src/.

…before it looked waitForAnimation polled getAnimations() after the action, so an entrance shorter than the first look (a cold page answers its first evaluate late) had already finished: "no animation started". The page now records every animation from the first call into curves.ts on it, and on every later document: a frame loop on its own requestAnimationFrame, the CSS animation and transition events, and Element.animate as it is called, pending animations included (WebKit can start and finish a short script animation between two frames of a fresh page). waitForAnimation also reports an animation that started after the last waitForRest or waitForAnimation and has finished, with finishedAt. watchAnimations(locator) arms the record before an action that may be the page's first contact with the harness.

…uest This pull request keeps the curve-sampling instruments: holding and seeking animations, sampling presented values, the oracles, waiting for an animation and for rest. The storyboards (storyboard.ts, the evidence output, the timer gate and the `pnpm storyboards` script) and their tests move to a pull request stacked on this one.

`holdAnimations` replaced the held set on each call, so a second hold left the first set paused after `releaseAnimations` (it resumed only the newest set), and `waitForRest` then reported the frozen frame as rest. A later hold now adds to the set: everything held stays held until the release, and offsets count from the earliest start of all of it. The self-test holds two elements in turn, releases, and checks the first runs to its end; on the old code it stays frozen 50 px into a 300 px move. The self-test's header and the `curves.ts` SYNC line no longer describe the storyboard and timer-gate layer, which moved to its own pull request.

@Storyboard

animationStoryboard films held animations by seeking them (t = 0, 16.7, 33.3 … ms, from the earliest start to the latest curve end among the animations that end, each at its own offset); touchStoryboard takes a frame per scripted touch event. Each writes a PNG contact sheet and a JSON trace of its measurements to the evidence directory and attaches them to the report; the spec asserts on the trace. The timer gate (installTimerGate, freezeTimers, thawTimers) holds the page's timers and frame callbacks while a storyboard photographs, so a component that finishes an animation from a timer cannot do it behind the held animation's back; the page can still cancel a held callback, and the harness's own frame waits (and the animation recorder) keep the page's real requestAnimationFrame. `pnpm storyboards` runs only the tests tagged @Storyboard.

`touchStoryboard` said velocity-dependent behavior is unchanged in Chromium. That holds for velocity read from event timestamps, which keep their scripted times, but a handler that reads `performance.now()` or `Date.now()` (Item's and Toast's swipes) sees one event per photograph, about 100 ms apart, so a flick that dismisses when played can settle back when filmed. The doc and the README now state that limit and point such gestures at a screencast, and a self-test shows both clocks: scripted 16.7 ms gaps in `timeStamp`, more than two frames in the handler's clock.

Timestamped composited frames (Chromium's screencast and WebKit's own), a marker the frames can find, and the busy-main-thread proof: block the page's main thread mid-flight and show the element still moving every frame, with a requestAnimationFrame animation that freezes as the negative control. Chromium trace counts of Layout, Paint and style work inside an animation window, and long tasks. The exemplar spec proves the BottomSheet drag to a detent with all of it: the drag follows the finger, a flick dismisses, the settle matches its timing function, keeps advancing through a blocked main thread in Chromium and WebKit, does no Layout or Paint, and gets a drag and settle storyboard.

…ed machine The proof asserted a stall under 40 ms and near-exact frame counts, so a dropped screencast frame or two on a loaded runner failed it, and frames delivered out of order read as the element stepping backwards. busyWindowProof now returns a verdict that tolerates what load does to a screencast and nothing a frozen animation does: a median frame interval of at most 20 ms, no stall longer than three screencast intervals, and at least 90% of the window's whole frame intervals presenting a new position (one miss always allowed), with the raw numbers in a summary. Screencast frames are sorted by presentation time, the cadence comes from the frames around the window, and blockMainThread can block from inside the page in the frame an animation has run, so a short settle is still judged at length on a busy machine. The exemplar judges its settle until it is within 2 px of rest, since the screencast rounds to whole pixels. A unit test covers the limits; the rAF negative control still fails every criterion.

…ading them from the animation The settle-curve oracle took its easing and duration from the animation under test, so it passed a 900 ms ease-in or a 150 ms linear settle as readily as the real one. The spec now asserts the theme's values (the default --ease-standard, cubic-bezier(0.24, 1, 0.4, 1), over the neutral theme's --duration-medium, 300 ms) and builds the oracle from them; the header no longer claims 410 ms.

…ebKit frames on its clock - `blockMainThread`'s `during` path ran its loop inside the rAF callback of the frame that saw the animation. WebKit hands a newly started animation to its compositor in that frame's rendering update, which runs after rAF callbacks, so the loop held the hand-off and even a compositor animation froze (2 of 29 frames moved). The loop now runs from a task queued in that frame. - WebKit's screencast frames were rebased onto the wall clock by taking the first frame as the start, which shifted every frame earlier by however long that frame took to come (60–100 ms). They are now rebased by the measured offset between the wall clock and CLOCK_MONOTONIC, which WebKit stamps them on. - `busyWindowProof` fails a judged part shorter than four frames (the animation under test was not moving during the block) instead of passing it, takes the end value from `settledAt` when given (WebKit can present a stale position once an accelerated animation ends while the main thread is blocked), and reports where the longest stall starts. - The BottomSheet busy case arms the block before the release and reads where the settle ends from the page.

Retargeting a CSS transition cancels it. If that happened while it was held, `seekAnimations` and `sampleCurve` set its time again, which revived it over the page's own new transition, and `releaseAnimations` replayed it from the start. Seeking, sampling and releasing now drop an `idle` animation from the held set first, and times count from a fixed origin (the earliest start held until the release), so dropping one never moves the others. The self-test retargets a held transition, seeks, releases and waits for rest: the cancelled transition stays idle and the box ends where the page sent it. On the old code the cancelled transition is still held after the seek.

# Conflicts: # internal/interaction-harness/src/harness.interaction.browser.spec.ts

… instrument `touchStoryboard`'s doc and the README pointed a clock-timed gesture at `startScreencast` and `castStoryboard`, which this branch does not have. They now say a storyboard cannot show such a gesture and to record it in real time.

…cast instruments With frame evidence in the harness, a clock-timed gesture a storyboard cannot show is recorded with `startScreencast` and `castStoryboard`: the doc and the README name them.

`pause()` only schedules the pause: the engine takes the hold time at its next frame, so a held animation stayed held a frame past `heldAtMs`, and a read right after the hold varied by a frame between runs. Setting the current time right after `pause()` completes a pending pause at once, where `heldAtMs` read it. The self-test holds a 1 s move and checks it is still at `heldAtMs` two frames later; on the previous code it reads one frame later in Chromium (16.6–16.7 ms) and 15–70 ms later in WebKit.

# Conflicts: # internal/interaction-harness/src/harness.interaction.browser.spec.ts

`blockMainThread({during})` counted an animation as running as soon as its current time reached `minProgressMs`. An animation created in the frame the page looks is still pending, not on the compositor yet, and at `minProgressMs: 0` the block started on it and froze it: in WebKit deterministically, and in Chromium on a Lightbox page while the block still ran inside the frame's callback. A pending animation no longer counts, and `minProgressMs` is raised to one frame (16 ms), since in WebKit an animation's start time resolves before its layer is flushed. The self-test creates the animation in the frame the helper looks and blocks at `minProgressMs: 0`. On the previous code it fails 6/6 in WebKit (0 frames presented through the block); now it passes 10/10 in WebKit and 6/6 in Chromium.

…here the engine has the Long Tasks API readLongTasks fails closed since meta#8320's 852d55c: it throws on WebKit, which has no Long Tasks API. The case keeps its drag and settle checks in both engines and asserts no long task in Chromium only, as the harness's own long-task tests gate on the engine.

… while it ran, with readLongTasks failing closed) into the BottomSheet detents

astracat-bot

Approval waits on an engineering owner's decision: BottomSheetDetent.interaction.browser.spec.ts pins outcomes that component:BottomSheet does not state yet, namely the nearest-detent settle after a still release, dismissal on a 2,000 px/s downward flick, and a settle that keeps advancing through a blocked main thread with no Layout or Paint. An engineering owner needs to provide the governing spec by recording which of these the BottomSheet contract states (for the compositor settle, by adopting spec:AST-094 FR5 for the drag settle, in which case the busy proof should also pass maxMedianFrameMs to assert display rate), or decide that the spec stops pinning them, and records that decision by commenting /approve-spec 24e9379dcd26de028f7d11bde296af9323ce1b3a on this pull request; as an engineering owner, the author may do so. Whatever that decision, these changes are needed:

The settle assertions (lines 199–202, with the curve checks at 213 and 233) pin a 300 ms cubic-bezier(0.24, 1, 0.4, 1) that leaves a 0 px/s release at 1,411 px/s, which spec:AST-094 FR38 rules out for BottomSheet; report them like the velocity hand-off instead of asserting them, unless FR38 is amended for BottomSheet.
Land #8045, #8548 and #8549 first and update the branch, so this pull request contains only its own change rather than 3,711 authored lines.

[Automated review]

…1's latest)

…e: wave 2, meta#8320 0567e2c, meta#8340 f5ac3e8 with meta#8076 cba0ad9, meta#8423 24e9379) into uikit/c24-zoom-geometry

…ly in Chromium) into meta#8105

, X1's meta#8423) into meta#8109

, X1's meta#8423) into meta#8128

… F1's meta#8076 3bfd7c3, X1's meta#8423) into meta#8203 # Conflicts: # packages/core/src/BottomSheet/BottomSheet.tsx # packages/core/src/BottomSheet/BottomSheetPanel.tsx

…xt with only meta#8548's own changes)

meta#8045 text with only this stack's own changes)

…ed) into meta#8423

astracat-bot

Approval waits on an engineering owner's decision: BottomSheetDetent.interaction.browser.spec.ts pins outcomes that component:BottomSheet does not state yet, namely the nearest-detent settle after a still release, dismissal on a 2,000 px/s downward flick, and a settle that keeps advancing through a blocked main thread with no Layout or Paint. An engineering owner needs to provide the governing spec by recording which of these the BottomSheet contract states (for the compositor settle, by adopting spec:AST-094 FR5 for the drag settle, in which case the busy proof should also pass maxMedianFrameMs to assert display rate), or decide that the spec stops pinning them, and records that decision by commenting /approve-spec 67d67e3de1635641e70b03d826f1d4b9175c851a on this pull request; as an engineering owner, the author may do so. Whatever that decision, one change is needed:

The settle assertions (lines 199–202, with the curve checks at 213 and 233) pin a 300 ms cubic-bezier(0.24, 1, 0.4, 1) that leaves a 0 px/s release at 1,411 px/s, which spec:AST-094 FR38 rules out for BottomSheet; report them like the velocity hand-off instead of asserting them, unless FR38 is amended for BottomSheet.

[Automated review]

…erting it The settle test asserted today's settle, the theme's 300 ms --ease-standard transition, frame by frame. That curve starts a release at rest at about 1,400 px/s, where spec:AST-094 FR38 starts a BottomSheet's release at the finger's speed, so the test pinned a curve the spec rules out. It now records the curve, its easing, its duration and its frame-by-frame fit, in the evidence and an annotation, as it already did for the velocity hand-off, and keeps asserting where the settle lands: the half detent.

The two carried harness hunks keep meta#8360's text, as on meta#8105.

…eta#8548 and meta#8549) into meta#8105 Two carried harness hunks met meta#8360's text, in the harness README and the header of the harness's own spec: meta#8360's side holds the offer's sentences plus its animation-recorder paragraph, so both keep meta#8360's text as it is.

…into meta#8105 BottomSheetDetent's settle test and header: this branch's, where the settle is UIKit's release spring, asserted frame by frame from the finger's velocity (spec:AST-094 FR38), which takes over the test meta#8423 now only records.

…and meta#8423's new base) into meta#8128

… the offered meta#8548/meta#8549 merges) into meta#8109 motion/README.md: the table takes meta#8360's presentation.ts row, and the uikit/sheet.ts row keeps this branch's clause, the rubber band past the tallest detent; Prettier realigns the table.

… curve) into meta#8109

…and meta#8423's new base) into meta#8203

astracat-bot

Approval waits on an engineering owner's decision: BottomSheetDetent.interaction.browser.spec.ts pins outcomes that component:BottomSheet does not state yet, namely the nearest-detent settle after a still release, dismissal on a 2,000 px/s downward flick, and a settle that keeps advancing through a blocked main thread with no Layout or Paint. An engineering owner needs to provide the governing spec by recording which of these the BottomSheet contract states (for the compositor settle, by adopting spec:AST-094 FR5 for the drag settle, in which case the busy proof should also pass maxMedianFrameMs to assert display rate), or decide that the spec stops pinning them, and records that decision by commenting /approve-spec dc418ea6ba443629b0141ff2bf046a913a4221ec on this pull request; as an engineering owner, the author may do so. The settle curve is now reported rather than asserted, and whatever that decision, these changes are still needed:

The settle test's landing check (lines 193–196 and 235) reads the CSS transform transition at 300 ms, so a settle that lands on the half detent but takes 500 ms fails it; assert where the sheet comes to rest, as the slow-drag test does at lines 161–162.
The description still lists the 300 ms cubic-bezier(0.24, 1, 0.4, 1) settle as a pinned outcome; update it so the owner decides on what the spec actually pins.

[Automated review]

astracat-bot · 2026-10-29T23:22:07Z

+    testInfo,
+  );
+  // Where it lands is asserted: the half detent.
+  expect(samples.at(-1)?.value).toBeCloseTo(halfTop - tallTop, 0);


This reads the held settle only as a CSS transform transition (lines 193–196 throw otherwise) and only at SETTLE_MS (sampled to 300 ms at line 202). With the panel's transition lengthened to 500 ms the sheet still rests on the half detent (top 357 px), but the value here is translateY(297.87px) against 299.875, so the test fails; a settle played as a script-created Web Animation, as the internal motion animator plays springs on translate, throws at line 195 first. Asserting where the sheet comes to rest, after releaseAnimations, keeps the landing check and leaves the curve as the record the header describes:

await waitForRest(sheet); expect(await sheetTop(sheet)).toBeCloseTo(halfTop, 0);

…#8423's new base) into meta#8386 MobilePowerSearch.test.tsx: the file is main's (its sheet flow now goes back from Add filter to Filters on a downward swipe), and the swipe test sends a finger as a touchscreen does, each pointer event with its touch event, on a sheet given a phone's box, as this branch's earlier swipe test did: with pointer events alone on jsdom's zero-height sheet it failed here (the flow stayed on Add filter). Its expectation is main's, unchanged.

…'s new base and meta#8342's head) into meta#8341

vjeux added 30 commits October 24, 2026 14:37

Merge branch 'main' into interaction-harness-2-curves

ffc2bd4

Merge branch 'interaction-harness-2-curves' into uikit/f3-storyboards

e918a2f

Merge branch 'uikit/f3-storyboards' into interaction-harness-3-frames

79a1fed

Merge branch 'interaction-harness-2-curves' into uikit/f3-storyboards

cb37bd7

# Conflicts: # internal/interaction-harness/src/harness.interaction.browser.spec.ts

Merge branch 'uikit/f3-storyboards' into interaction-harness-3-frames

0b4d12b

# Conflicts: # internal/interaction-harness/src/harness.interaction.browser.spec.ts

Merge branch 'uikit/f3-storyboards' into interaction-harness-3-frames

212ec1d

docs(interaction): the touch filmstrip's clock limit names the screen…

b36bf63

…cast instruments With frame evidence in the harness, a clock-timed gesture a storyboard cannot show is recorded with `startScreencast` and `castStoryboard`: the doc and the README name them.

Merge branch 'interaction-harness-2-curves' into uikit/f3-storyboards

b5783ed

# Conflicts: # internal/interaction-harness/src/harness.interaction.browser.spec.ts

Merge branch 'uikit/f3-storyboards' into interaction-harness-3-frames

2a718ad

# Conflicts: # internal/interaction-harness/src/harness.interaction.browser.spec.ts

vjeux added 2 commits October 26, 2026 19:00

Merge meta#8549 (2a6b934: the compositor record refuses a page opened…

24e9379

… while it ran, with readLongTasks failing closed) into the BottomSheet detents

vercel Bot deployed to Preview October 27, 2026 03:37

View deployment

astracat-bot Bot reviewed Oct 27, 2026

View reviewed changes

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 27, 2026

Merge commit '24e9379dcd26de028f7d11bde296af9323ce1b3a' (facebook#8423,…

5002a78

…1's latest)

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 27, 2026

Merge X1's meta#8423 (24e9379: the slow-drag case reads long tasks on…

78eb12b

…ly in Chromium) into meta#8105

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 27, 2026

Merge meta#8105 (78eb12b: F2's meta#8320 528e3e1, F1's meta#8076 3bfd7c3

5d2db09

, X1's meta#8423) into meta#8109

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 27, 2026

Merge meta#8109 (5d2db09: F2's meta#8320 528e3e1, F1's meta#8076 3bfd7c3

8556570

, X1's meta#8423) into meta#8128

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 27, 2026

Merge meta#8423 (24e9379: the Detent spec) into the meta#8105 base

8290108

vjeux added 3 commits October 28, 2026 10:38

Merge main 70ea859 into meta#8548 (harness files: main's meta#8045 te…

e04826c

…xt with only meta#8548's own changes)

Merge the main merge of meta#8548 into meta#8549 (harness files: main's

ec8a345

meta#8045 text with only this stack's own changes)

Merge merge/8549-main ec8a345 (meta#8549 and meta#8548 with main merg…

67d67e3

…ed) into meta#8423

vercel Bot deployed to Preview October 29, 2026 17:23

View deployment

astracat-bot Bot reviewed Oct 29, 2026

View reviewed changes

vjeux marked this pull request as draft October 29, 2026 22:36

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 29, 2026

Merge meta#8423 67d67e3 into the meta#8105 base

7872047

The two carried harness hunks keep meta#8360's text, as on meta#8105.

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 29, 2026

Merge meta#8423 dc418ea into the meta#8105 base

99583cd

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 29, 2026

Merge meta#8109 b53ab73 (meta#8105 on meta#8360's gesture foundation …

02b4ccd

…and meta#8423's new base) into meta#8128

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 29, 2026

Merge meta#8105 72db163 (meta#8423's detent spec records the settle's…

e6611d4

… curve) into meta#8109

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 29, 2026

Merge meta#8128 02b4ccd (the stack on meta#8360's gesture foundation …

6fb24f4

…and meta#8423's new base) into meta#8203

vercel Bot deployed to Preview October 29, 2026 23:03

View deployment

astracat-bot Bot reviewed Oct 29, 2026

View reviewed changes

vjeux added a commit to vjeux/astryx that referenced this pull request Oct 30, 2026

Merge meta#8203 c9a4606 (the stack on meta#8360's foundation, meta#8423…

6c0b3ed

…'s new base and meta#8342's head) into meta#8341

Navigation Menu

Repository navigation

test(core): BottomSheet detents, proven with the interaction harness - #8423

test(core): BottomSheet detents, proven with the interaction harness#8423
vjeux wants to merge 156 commits into
meta:mainfrom
vjeux:uikit/f3-bottomsheet-detent

vjeux commented Oct 25, 2026 •

edited

Loading

Uh oh!

astracat-bot Bot left a comment

Uh oh!

astracat-bot Bot left a comment

Uh oh!

astracat-bot Bot left a comment

Uh oh!

astracat-bot Bot Oct 29, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

vjeux commented Oct 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Maintainer impact

Intended invariant

Change

Evidence

Scope

Testing

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot Oct 29, 2026

Choose a reason for hiding this comment

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vjeux commented Oct 25, 2026 •

edited

Loading