fix: <vimeo-video> element race condition

[spuppo-mux]

By checking logs I saw that when the bug happened, we were getting into the isInit === false case (and load was running just one time), so the options weren't being applied.

Tested this mainly on nextjs example. Could originally reproduce semi-consistently by switching to TikTok player and then back to vimeo. When the bug happens we see the Vimeo default color (blueish)

When the config applies correctly we should see a pinkish color

To address the race condition:

• Moved await (this.#loadRequested = Promise.resolve()); to the top of the function
• Added a disconnectedCallback to clear state on unmount.

Extra:

• Code clearness:
  • Moved api listener setup into a new #setupApiListeners function
  • Moved #onLoaded listener to a new method since it's now used from two functions
  • Restrctured "if else" at the bottom of load function so it's clearer to read.
• Open points (non-blocking):
  • Noticed that isInit and hasLoaded are pretty similar semantically, was wondering if one of them can be removed.
  • Added options to new VimeoPlayerAPI call (did not seem to have effect even though it's specified in the JSdocs)

/**
   * Create a Player.
   *
   * @param {(HTMLIFrameElement|HTMLElement|string|jQuery)} element A reference to the Vimeo
   *        player iframe, and id, or a jQuery object.
   * @param {object} [options] oEmbed parameters to use when creating an embed in the element.
   * @return {Player}
   */

---

Note

Medium Risk
Changes the vimeo-video-element load sequencing and lifecycle state reset, which can affect initialization timing and event ordering across mounts/unmounts.

Overview
Fixes a race in VimeoVideoElement.load() by moving the one-tick #loadRequested gate earlier, so attribute/config updates settle before initialization and options are reliably applied.

Refactors load completion handling by extracting #onLoaded() and listener wiring into #setupApiListeners(), passing options into new VimeoPlayerAPI(...), and adding disconnectedCallback() to clear internal init/load flags and reset loadComplete when the element unmounts.

^{Written by Cursor Bugbot for commit 359a7fc. This will update automatically on new commits. Configure here.}

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[vercel]

@spuppo-mux is attempting to deploy a commit to the Mux Team on Vercel.

A member of the Team first needs to authorize it.

[spuppo-mux]

Closes #219

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Reordered loadComplete refresh enables null api dereference

Medium Severity

Moving if (this.#hasLoaded) this.loadComplete = new PublicPromise() from before the 1-tick await to after it introduces a timing regression on second+ loads. When src and loop change in the same synchronous block (common in React/Next.js), the loop handler's await this.loadComplete resolves immediately on the stale promise. Its continuation then runs after load() sets this.api = null, causing this.api.setLoop(...) to throw a TypeError. Previously, loadComplete was refreshed before the await, so the loop handler would correctly suspend until the new load completed.

Additional Locations (1)

• packages/vimeo-video-element/vimeo-video-element.js#L358-L365