Keeping unmuted video autoplay alive in Safari: per-element blessing, the ~5s activation window, and the silent-start trap

Building a TikTok-style looping video feed (one autoplaying card at a time, crossfading audio between cards) surfaces three WebKit behaviors that Chrome's autoplay documentation will not prepare you for. Symptoms: sound randomly 're-muting' mid-scroll, sound always lost after page navigation, and the first video of a page load ending up paused instead of playing. Verified on Safari 18-era WebKit (macOS) and headless Chromium 130+, in an Astro 7.1 static site; the behaviors are policy-level and not version-fragile.

First: user activation is per-document and dies on every full page load. No browser carries activation across an MPA navigation. Chrome alone permits unmuted autoplay after a same-origin click-through navigation (its engagement exception), so an MPA feed keeps sound in Chrome but never in Safari. The only real fix for Safari is making navigations same-document (a client-side router; in Astro 3+, <ClientRouter /> from astro:transitions), so the persisting document keeps both its activation history and your module state, and the nav click itself provides fresh transient activation for the first play on arrival.

Second: transient activation is a short timer (~5 s in WebKit, see webkit.org/blog/13862) refreshed by pointerdown/keydown - and wheel/trackpad scrolling never refreshes it. So in a feed where scrolling triggers play() on the next card's fresh <video>, any flip more than ~5 s after the last real input rejects with NotAllowedError. This is why the failure feels intermittent: flips right after a tap or keypress succeed, later ones fail. The durable fix is WebKit's per-element grant model (webkit.org/blog/7734): once an element has been played from a real gesture, that element keeps its audible-playback right for the session. Instead of one <video> per card, route all playback through a small persistent pool (front/back pair, src-swapped and crossfaded), and bless every pooled element during a real gesture:

// Bless all pooled media elements on the first real gestures.
// play() inside the handler grants the element WebKit's per-element
// audible-playback right permanently; load() works for src-less elements.
function blessPools(): void {
  for (const v of [feedFront, feedBack, tvFront, tvBack]) {
    if (v.dataset.blessed === "1") continue;
    if (v.src) {
      if (v.paused) { v.play().catch(() => {}); v.pause(); }
      else v.play().catch(() => {}); // no-op resume, still blesses
    } else v.load();
    v.dataset.blessed = "1";
  }
}
document.addEventListener("pointerdown", blessPools, { capture: true });
document.addEventListener("keydown", blessPools, { capture: true });

One real tap licenses audible playback for the rest of the session regardless of scroll distance.

Third, the silent-start trap: WebKit will happily allow an unmuted play() at volume = 0 - and then auto-pause the video the moment your fade-in makes it audible without a gesture. If you implement crossfades as 'start at volume 0, ramp to 1', a fresh page load plays for ~250 ms and freezes. Gate the fade on sticky activation:

if (unmuted && incoming) {
  video.muted = false;
  if (navigator.userActivation?.hasBeenActive) {
    video.volume = 0;          // gesture exists: fade-in is safe
    fadeVolume(video, 1);
  } else {
    video.volume = 1;          // fresh document: let play() adjudicate
  }                            // audibility atomically - never
}                              // silent-start-then-fade here
video.play().catch((err: DOMException) => {
  if (err.name === "NotAllowedError") {
    // degrade to muted with a truthful mute icon; keep the stored pref
  }
});

Either sound is allowed and persists, or you get a clean NotAllowedError to catch and degrade to muted playback. Never let an inaudible start succeed only to be killed mid-fade.

Two smaller notes from the same work. Detach a pooled media element from the DOM (el.remove()) before re-sourcing it for preload: an element still parented in the previous card's container repaints its poster the instant src changes, flashing the wrong poster. And 'volume-up key to unmute' cannot be built for Safari: macOS/iOS consume hardware volume keys before the page sees them, the Media Session API defines no volume actions, and HTMLMediaElement.volume is read-only on iOS.

Recommendation: treat Chrome's behavior as the exception, not the baseline. Design for WebKit's model - per-element grants, a persistent blessed pool, same-document navigation, full-volume atomic play attempts on gestureless documents with NotAllowedError as the muted-degrade signal - and Chrome works automatically.