fix: defer load() until connected to prevent metadata race on first Mux Data beacon

[R-Delfino95]

Problem

Fixes #1199

When <mux-player> (or <mux-video>) is created programmatically and attributes are set before the element is appended to the DOM — with any async yield between attribute setting and appendChild (e.g. await Promise.resolve(), React's async reconciliation, Next.js rendering, etc.) — the first Mux Data analytics beacon is sent with an incorrect video_id.

Root cause: mux-video.#requestLoad() schedules load() in a microtask via await Promise.resolve(). Under the following sequence, that microtask fires before mux-player.connectedCallback has a chance to propagate metadata-* attributes to the inner <mux-video>:

const el = document.createElement('mux-player');
el.setAttribute('playback-id', '...');
el.setAttribute('metadata-video-id', 'my-custom-video-id'); // not in observedAttributes
await Promise.resolve(); // ← load() microtask fires here — metadata is empty
document.body.appendChild(el);  // connectedCallback propagates metadata too late

metadata-* attributes are not in mux-video's observedAttributes. They are read lazily from the element's own DOM attributes by the metadata getter. Since mux-player's template does not forward metadata-* attributes to the inner , propagation only happens in mux-player.connectedCallback. Any async gap before appendChild causes the first mux.monitor() call — which sets video_id permanently for the view — to receive empty metadata. Because video_id is fixed at view start and cannot be corrected retroactively, the beacon is permanently wrong.

Fix

Added an isConnected guard inside mux-video's #requestLoad()

When the element is not yet connected at microtask time, the deferred load() is skipped. The existing connectedCallback already re-triggers #requestLoad() once the element connects (guarded by !this.#core), so load() runs after mux-player.connectedCallback has propagated metadata

---

Note

Medium Risk
Changes MuxVideoBaseElement initialization timing and tracking reload behavior, which can affect when playback-core is initialized and when Mux Data beacons start firing. Risk is limited to element lifecycle edge cases but could impact analytics or autoplay/resume flows if misordered.

Overview
Defers MuxVideoBaseElement load() execution until the element is actually connected (isConnected guard inside #requestLoad()), preventing the initial Mux Data beacon from firing before parent elements (e.g. mux-player) can propagate metadata-* attributes.

Adjusts disable-tracking attribute handling to skip unload/reload while disconnected, avoiding a .then() resume path that would run without a corresponding load(); connectedCallback will re-trigger #requestLoad() once connected.

^{Reviewed by Cursor Bugbot for commit f845ff3. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

@R-Delfino95 is attempting to deploy a commit to the Mux Team on Vercel.

A member of the Team first needs to authorize it.

[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.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

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

^{Reviewed by Cursor Bugbot for commit e4944fc. Configure here.}

[luwes]

actually could we solve this without preventing the load() to go through when not connected?