Investigate #3407: same root cause as #3265, fixed in #3593

[mattgperry]

Fixes #3407 (recommend closing as already fixed)

Summary

Issue #3407 reports a Chrome-only spring animation bug where a useSpring-driven cursor follower feels "stuck" and resists orbiting the cursor. After investigation, this appears to be the same root cause as #3265, which was already fixed by PR #3593 (commit e93102089, shipped in v12.35.2 and later).

This PR is a draft for tracking purposes — no fix is required. The only diff is a test rename annotating that #3407 is covered by the existing regression gate at packages/motion-dom/src/value/__tests__/follow-value-framerate.test.ts.

Background

• 2026-01-22 — Issue [BUG] Spring animation is broken on Chrome (works on Firefox/Safari) (Mac) #3407 reported. Maintainer asked the reporter to test 12.29.1-alpha.0. That alpha did not yet contain the velocity-preservation fix.
• 2026-03-02..03 — A previous attempt (Fix spring animation velocity loss on Chrome (vsync-aligned mousemove) #3577) added a sampleAt/canSampleVelocity API to JSAnimation to read pre-stop velocity via a 5ms finite difference. Closed without merge.
• 2026-03-04 — PR Fix laggy spring animations at 240hz refresh rates #3593 landed commit e93102089 ("Fix laggy spring animations at high refresh rates (240hz)") which addresses the same root cause more cleanly: it adds JSAnimation.getGeneratorVelocity() (analytical derivative from the spring formula) and reads it in attachFollow.startAnimation() before stopping the active animation. It also stabilises the frame.postRender reference so multiple per-frame events deduplicate.

Why #3407 and #3265 are the same bug

Both reports trace to:

attachFollow's startAnimation() reads value.getVelocity() after calling stopAnimation(). When the spring is interrupted after only one frame (Chrome vsync-aligned mousemove, or any 240hz display), getVelocity() returns a cross-animation finite difference that collapses to ~0, so the spring restarts with no velocity and feels stuck.

Current follow-value.ts already does the right thing:

const velocity = activeAnimation
    ? activeAnimation.getGeneratorVelocity()
    : value.getVelocity()

Verification

packages/motion-dom/src/value/__tests__/follow-value-framerate.test.ts simulates a moving target at 60hz vs 240hz with vsync-aligned interruptions every frame:

• With the current fix, 240hz tracks within 10% of 60hz.
• Reverting the getGeneratorVelocity() line back to value.getVelocity() drops the ratio to ~0.78 — the test fails for the right reason and reproduces the "stuck" behaviour described in [BUG] Spring animation is broken on Chrome (works on Firefox/Safari) (Mac) #3407.

Recommendation

Ask the reporter to upgrade to v12.35.2 or later (current latest: v12.38.0). If they still see the regression on the latest version, reopen with a fresh CodeSandbox so we have a real repro to chase.

Test plan

• follow-value-framerate.test.ts passes against current main
• follow-value-framerate.test.ts fails when getGeneratorVelocity() is reverted to value.getVelocity() (ratio 0.78 < 0.9)
• yarn build succeeds
• yarn test — 793 passed, 7 skipped, 0 failed

[greptile-apps]

Greptile Summary

This PR makes no functional changes — the only diff is renaming the describe block in follow-value-framerate.test.ts from "…(issue #3265)" to "…(issues #3265, #3407)", annotating that the existing regression gate also covers issue #3407.

• Test rename only: The describe string in follow-value-framerate.test.ts is updated to credit both issues; no logic, assertions, or setup code is touched.
• Tracking PR: The PR serves as a documentation artifact confirming that the spring-velocity bug from [BUG] Spring animation is broken on Chrome (works on Firefox/Safari) (Mac) #3407 was already resolved in v12.35.2 via the getGeneratorVelocity() fix landed in Fix laggy spring animations at 240hz refresh rates #3593.

Confidence Score: 5/5

Safe to merge — the entire change is a one-word addition to a test description string with no effect on runtime behaviour or test logic.

The only changed line is the describe block label in a test file. No assertions, no setup, no production code, and no imports are touched. The underlying regression gate continues to pass unchanged, and the rename accurately reflects the dual-issue coverage.

No files require special attention.

Important Files Changed

Filename	Overview
packages/motion-dom/src/value/tests/follow-value-framerate.test.ts	Single-line describe-block rename to credit issues #3265 and #3407; no logic changes.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Issue #3407 reported\n(Chrome spring stuck)"] --> B["Root cause traced:\ngetVelocity() returns ~0\nafter single-frame stop"]
    B --> C["Same root cause as #3265"]
    C --> D["Already fixed in PR #3593\ngetGeneratorVelocity() added"]
    D --> E["follow-value-framerate.test.ts\ndescribe block renamed\nto reference #3265 + #3407"]
    E --> F["No code change needed\n✅ Covered by existing test"]

Loading

_{Reviews (1): Last reviewed commit: "Investigate #3407: link existing #3265 f..." | Re-trigger Greptile}