🐛 Bug: SliderPreview's animationFrameThrottle frame outlives destroy() — "disabled is not a function" on unmount

[naghtigal]

Current Behavior:

Unmounting a MediaPlayer in the same task in which a SliderPreview connects throws an uncaught TypeError from a requestAnimationFrame callback — one per slider preview.

TypeError: disabled is not a function
    at #isDisabled                        (@vidstack_react.js:8515)
    at SliderPreviewInstance.<anonymous>   (@vidstack_react.js:8045)
    at chunk-Z5L6KLLP.js:604               (animationFrameThrottle's rAF callback)

SliderPreview.onConnect schedules #updatePlacement from both an effect() and a ResizeObserver:

#updatePlacement = animationFrameThrottle(() => {
  const { disabled, orientation } = this.#slider;
  if (disabled()) return;                  // <- throws here
  ...
});

animationFrameThrottle keeps the frame id in a closure and returns a bare function, so there is nothing to cancel on dispose:

function animationFrameThrottle(func) {
  let id = -1, lastArgs;
  function throttle(...args) {
    lastArgs = args;
    if (id >= 0) return;
    id = window.requestAnimationFrame(() => {
      func.apply(this, lastArgs);          // still runs after destroy()
      id = -1;
      lastArgs = void 0;
    });
  }
  return throttle;                         // no .cancel()
}

Meanwhile ComponentInstance.destroy() blanks props and state:

this.props  = EMPTY_PROPS;
this.$state = null;

this.#slider.disabled is the owning slider's #isDisabled, which reads const { disabled } = this.$props. After destroy(), $props is EMPTY_PROPS, so disabled is undefined and calling it throws.

Because the React wrapper defers both connect and destroy to setTimeout, they interleave with the queued frame:

1. React commits the player; the wrapper schedules the preview's connect timer.
2. The player unmounts; the wrapper schedules the destroy timer (after the connect timer).
3. Connect timer runs → effect(#updatePlacement) → requestAnimationFrame(...) queued.
4. Destroy timer runs → props = EMPTY_PROPS.
5. The queued frame fires → disabled() → TypeError.

Expected Behavior:

Tearing a player down should not throw. A pending placement frame belonging to a destroyed component should be cancelled, or should no-op.

Suggested fix — give animationFrameThrottle a cancel() and call it on dispose:

throttle.cancel = () => {
  if (id >= 0) window.cancelAnimationFrame(id);
  id = -1;
  lastArgs = void 0;
};

// SliderPreview.onConnect
onDispose(() => this.#updatePlacement.cancel());

Steps To Reproduce:

1. npm install
2. npm run dev, open http://localhost:5173
3. The page mounts a player and unmounts it as soon as the slider previews connect. It reports REPRODUCED and prints the errors caught on window.onerror.

There is also a headless check: npx playwright install chromium && npm run verify (exits 1 when the crash reproduces).

Rate: 8–10 out of 10 page loads in dev, 19/20 against vite build + vite preview. It is a frame race, so an occasional load survives. Only the first player mount in a page's lifetime races — re-running in-page always passes — so the repro re-runs via a full reload.

Reproduction Link: https://github.com/naghtigal/vidstack-slider-preview-repro

I used a plain Vite repo rather than StackBlitz deliberately: this is a timing race between a queued animation frame and a deferred destroy, and I did not want a WebContainer iframe's scheduling to mask it. Happy to port it to StackBlitz if you'd prefer.

Environment:

• Framework: React 19.2
• @vidstack/react: 1.15.6
• Meta Framework: none (Vite 7)
• Node: 24
• Device: MacBook (arm64)
• OS: macOS 15
• Browser: Chrome 150 (also reproduces on Playwright's bundled Chromium)

Anything Else?

No media source and no layout package are required — SliderPreview.onConnect running is the only requirement. DefaultVideoLayout has two slider previews (time + volume), so a teardown there produces exactly two of these errors, which is what the repro mirrors.

The throw happens inside a requestAnimationFrame callback, so it surfaces on window.onerror rather than in a React error boundary. It is non-fatal — React keeps rendering — but it is uncaught, so it lands in error reporting.

Possibly related: #1753 reports this.$state[prop2] is not a function on rapid mount/unmount cycles. Different code path (a pending play() promise rather than a queued frame), but the same shape — async work outliving destroy() after it has blanked props/$state. A general "cancel in-flight work on dispose" pass might cover both.

[naghtigal]

Bisected this — it is a regression in 1.14.0, and it only manifests on React 19.

Version bisect

Measured with the linked repro plus a second harness using DefaultVideoLayout with real media (closer to normal usage). Each run is gated on the slider previews actually having connected, so a "clean" result is not a harness that silently failed to run.

@vidstack/react	uncaught errors on teardown
1.12.13	clean (0/12)
1.13.1	clean (0/12) — last good
1.14.0	crashes — first bad
1.15.0	crashes
1.15.6	crashes (7/12)

What changed in 1.14.0

SliderPreview is byte-identical between 1.13.1 and 1.14.0. The change is in the React wrapper's scheduling — connectId, refChangeId and destroyId all moved from requestAnimationFrame to setTimeout:

- state.connectId   = window.requestAnimationFrame(...)
- state.refChangeId = window.requestAnimationFrame(...)
- state.destroyId   = window.requestAnimationFrame(...)
+ state.connectId   = window.setTimeout(...)
+ state.refChangeId = window.setTimeout(...)
+ state.destroyId   = window.setTimeout(...)

That ordering was what had been hiding the missing cancel():

• Before 1.14.0 — destroy() ran as an rAF callback, queued after the placement frame that SliderPreview.onConnect had already scheduled. rAF callbacks run FIFO, so placement ran first, against a live component. No crash.
• From 1.14.0 — destroy() is a macrotask, and macrotasks run before the next frame's rAF callbacks. So props is set to EMPTY_PROPS first, and the still-pending placement frame then fires against the destroyed component.

So the un-cancellable animationFrameThrottle has been there since 1.10.0 (that is when #updatePlacement was first wrapped), but 1.13.1 and earlier avoided it by accident. 1.14.0 removed the accidental ordering rather than introducing the underlying defect — which I think makes the suggested fix (an explicit cancel() called from onDispose) more worthwhile than restoring the old scheduling, since the current code depends on an ordering coincidence.

React 18 vs 19

Same harness, same @vidstack/react@1.15.6, only the React major swapped:

React	result
18.3.1	clean (0/10)
19.2.8	crashes (8/10)

I confirmed this behaviour but did not chase down why React 19's commit/cleanup timing changes the interleaving, so I won't guess at the mechanism.

Notes

• The linked repro pins 1.15.6; setting @vidstack/react to 1.13.1 in it makes the crash disappear, and 1.14.0 brings it back.
• Minor, possibly unrelated: on 1.13.x the minimal repro (bare sliders, no src) throws Cannot read properties of null (reading 'addEventListener') on unmount instead. That does not occur on 1.13.1 with DefaultVideoLayout and a real source, so it may just be an artifact of the stripped-down setup — flagging it in case it points at something real.