plans/issues/issue-2504.md
Executor instructions: Follow step by step; run every verification command. STOP conditions are binding. When done, update (or add) this plan's row in
plans/issues/README.md.Drift check (run first):
gh api repos/motiondivision/motion/issues/2504 --jq .state→ expectopen. If closed, STOP.
plans/issues/issue-2500.md regression tests)42bfbe3ed, 2026-06-11Reported Jan 2024: "spam hover" on a box pauses/starts a progress-bar animation
and it "slows down"; reporter expects resume to take exactly the remaining time.
Two later +1 comments (2024-11, 2026-02). The sandbox
(codesandbox.io/p/sandbox/framer-custom-slider-dots-forked-q1wr4) is
inaccessible during planning — both the legacy API
(codesandbox.io/api/v1/sandboxes/q1wr4) and the page return Cloudflare
403/challenge — so the actual API usage is unknown, and it decides everything:
controls.pause() / controls.play(): that path
preserves remaining time exactly on current code (verified empirically at
42bfbe3ed, and being pinned by the #2500 regression tests in
plans/issues/issue-2500.md). A 2024 version may have shown drift, fixed since..stop() (or re-trigger variants/animate()) on
hover-end: starting a new animation from the interrupted value with the
full configured duration is by design — keyframes re-resolve from the
current value and the full duration applies to the remaining distance, which
reads as "slowing down". The answer is to use pause()/play().Repo policy: no repro → no fix — without the sandbox code we must not guess a defect or land speculative coverage.
| Purpose | Command | Expected |
|---|---|---|
| Re-try sandbox (once) | curl -s --max-time 20 "https://codesandbox.io/api/v1/sandboxes/q1wr4" | head -c 400 | JSON with modules (else Cloudflare HTML) |
| Comment | gh issue comment 2504 --body-file <file> | comment URL |
| Close (gated) | gh api -X PATCH repos/motiondivision/motion/issues/2504 -f state=closed -f state_reason=not_planned | closed |
In scope: one issue comment; gated close; this plan's README row. Out of scope: ANY source/test change. If the sandbox turns out to show a real pause/play timing defect, STOP and report — that becomes a new FIX plan.
Run the curl above (and only that — don't burn time on scraping workarounds). If it returns module sources, read the hover handlers and re-classify per the two branches in "Why this matters"; report back instead of continuing if a real defect is visible.
Post a comment covering:
animate/useAnimation call) or a
fresh sandbox on a current motion release.controls.pause()/controls.play()
resumes with the remaining time (now covered by regression tests); calling
.stop() and re-starting creates a new animation that re-resolves from the
current value with the full duration — by design, and the likely cause of
the observed "slowdown".ONLY after this plan's row in plans/issues/README.md is marked APPROVED:
gh api -X PATCH repos/motiondivision/motion/issues/2504 -f state=closed -f state_reason=not_planned
(needs-repro: no reproduction obtainable; likely usage of restart semantics).
If not APPROVED, set the row to BLOCKED("awaiting close approval") and stop.
git status cleanplans/issues/README.md row updatedpause()/play() usage that still misbehaves
on current code — report back for a FIX plan instead of closing.