Browser autoplay restrictions and playback permission

Browser autoplay restrictions govern when media may begin without suitable user interaction, making a playback request’s promise result part of the player’s state.

A browser can refuse to begin media without an appropriate user interaction, even when the resource and codecs are supported. Autoplay restrictions govern permission to start, including circumstances involving audible media.

This explains why a video can be ready while its player still presents a Play button.

Requesting playback is an action with a result

The HTML autoplay attribute expresses a request; the browser's applicable policy determines whether automatic presentation can begin. Muted and audible media can be treated differently.

Chrome's documented policy is one concrete example: it distinguishes muted autoplay from audible autoplay and considers factors such as user interaction and permitted embedded playback. Other browsers and embedded views have their own applicable behavior.

A player should react to the result of its start request. This original example assumes video is the selected media element and the functions update the application's visible controls:

async function requestStart() {
  try {
    await video.play();
    showPlayingControls();
  } catch (error) {
    showPlayButton(error.name);
  }
}

The code does not claim playback is running merely because it called play(). If the promise rejects, the app can expose a usable action and retain the error context.

Separate permission from media preparation

Observation Question it raises
play() rejects with NotAllowedError Was playback permitted under the applicable policy?
The user clicks Play and presentation starts Did that interaction provide the required permission?
The resource request fails Could the media be obtained?
A decoder reports failure after data is obtained Could this encoded media be prepared?
Playback starts and later stalls Is the next required media ready?

A NotAllowedError is not a codec identifier. Conversely, a user gesture does not repair an inaccessible resource or an unsupported encoding.

In an Emby Web session, this distinction can prevent a ready-but-paused player from being mistaken for slow transcoding. The server can already have useful output while the browser is waiting for permission to present it.

Embedded playback has another context

An embedded player can be affected by its embedding page's permission policy. User interaction in one frame is not a universal instruction that every unrelated frame must start audible media.

Applications need to preserve the intended interaction and examine the actual promise result. A successful user-triggered start can update the controls immediately; a rejected start should leave the user an action that corresponds to the browser's state.

See Also

References