Add regression test for linear motion-value animation (#2826)

[mattgperry]

Summary

Adds a regression test mirroring the exact reproduction from issue #2826:
useMotionValue(0) + animate(value, [0, 1], { ease: "linear", type: "keyframes", times: [0, 1] }) driving motion.div opacity. The test asserts the rendered opacity tracks linearly at the 25 %, 50 %, and 75 % marks of a 10 s animation.

Investigation

The user's repro uses framer-motion 6.2.8 (Feb 2022). On the current main, both the JS animation pipeline (JSAnimation + the keyframes generator) and the rendered DOM opacity progress linearly — I could not reproduce the reported flicker at 50 % in Jest (JSDOM) or in Cypress (Electron Chrome, React 18 and React 19). The likely culprit was fixed incidentally during the rewrite of the animation pipeline between v6 and v12.

Rather than landing speculative code changes for a bug I cannot trigger, this PR locks in the desired behavior so a regression to the original buggy state would fail CI.

• Test page: dev/react/src/tests/issue-2826-linear-motion-value.tsx
• Cypress spec: packages/framer-motion/cypress/integration/issue-2826-linear-motion-value.ts

Fixes #2826

Test plan

• yarn build succeeds
• yarn test — 797 tests pass
• Cypress spec passes on React 18 (Vite dev server, headed Electron)
• Cypress spec passes on React 19 (Vite dev server, headed Electron)

[greptile-apps]

Greptile Summary

Adds a regression test for issue #2826 — useMotionValue(0) animated with { ease: "linear", type: "keyframes" } should track opacity linearly. The bug cannot be reproduced on current main (likely fixed during the v6→v12 pipeline rewrite), so this PR locks in the correct behavior with a Cypress spec that would catch any future regression.

• Test page (dev/react/src/tests/issue-2826-linear-motion-value.tsx): mounts a motion.div whose opacity is driven by a useMotionValue animated over 10 s; auto-discovered by the import.meta.glob pattern in App.tsx.
• Cypress spec (packages/framer-motion/cypress/integration/issue-2826-linear-motion-value.ts): waits at the 2.5 s, 5 s, and 7.5 s marks and asserts opacity is within ±0.1 of 0.25, 0.5, and 0.75 respectively.

Confidence Score: 4/5

Safe to merge — only adds test files with no changes to library source code.

The Cypress spec relies entirely on wall-clock cy.wait() delays and a ±0.1 opacity tolerance. A mild non-linear easing regression could stay within those bounds undetected, and the suite could become flaky on slower CI runners. Neither concern blocks merging, but the spec would benefit from tighter assertions (via cy.clock()/cy.tick()) to serve as a stronger long-term regression guard.

The Cypress spec (packages/framer-motion/cypress/integration/issue-2826-linear-motion-value.ts) is the only file worth a second look — the test page itself is straightforward.

Important Files Changed

Filename	Overview
dev/react/src/tests/issue-2826-linear-motion-value.tsx	New test page that reproduces the exact scenario from issue #2826: useMotionValue + animate() with linear ease driving a motion.div opacity, auto-discovered by the glob-based import in App.tsx with no registration required.
packages/framer-motion/cypress/integration/issue-2826-linear-motion-value.ts	Cypress spec that asserts opacity tracks linearly at 25%, 50%, and 75% of a 10s animation using wall-clock waits; element reference is correctly reused across .then() blocks via Cypress subject propagation, but the timing approach is inherently sensitive to CI load.

Sequence Diagram

sequenceDiagram
    participant Cypress
    participant Browser
    participant React
    participant MotionValue

    Cypress->>Browser: "cy.visit(?test=issue-2826-linear-motion-value)"
    Browser->>React: mount App
    React->>MotionValue: useMotionValue(0)
    React->>MotionValue: "animate(opacity, [0,1], {duration:10, ease:linear})"
    MotionValue->>Browser: "updates #box style.opacity on each RAF"

    Cypress->>Cypress: wait(2500ms)
    Cypress->>Browser: "get(#box).then() - getComputedStyle.opacity approx 0.25"

    Cypress->>Cypress: wait(2500ms)
    Cypress->>Browser: then() - getComputedStyle.opacity approx 0.50

    Cypress->>Cypress: wait(2500ms)
    Cypress->>Browser: then() - getComputedStyle.opacity approx 0.75

Loading

_{Reviews (1): Last reviewed commit: "Add regression test for linear motion-va..." | Re-trigger Greptile}

[greptile-apps]

Stale subject reuse for 50 % and 75 % checks

After the first .then() returns undefined, Cypress keeps the original jQuery subject from .get("#box") and passes it through the subsequent .wait()/.then() calls. This works correctly because $element is a live DOM reference and getComputedStyle reads the current value at call time — but the pattern is subtle. If this chain is ever refactored (e.g. an early return is added, or a cy.wrap() is inserted), the 2nd and 3rd .then() blocks could silently receive the wrong subject. Consider re-querying with .get("#box") before each check for clarity and resilience.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Tolerance may be too wide to catch subtle regressions

A tolerance of 0.1 (±10 %) means the test passes as long as opacity is anywhere between 0.15–0.35, 0.40–0.60, and 0.65–0.85. A regression that replaced the linear ease with a mild ease-in or ease-out curve could produce values that fall inside those windows and go undetected. The wide band is understandable for wall-clock–based CI timing, but pairing it with cy.clock() / cy.tick() would allow a much tighter tolerance (e.g. 0.02) and make this a stronger regression guard without flakiness risk.