[Web Media F2F] Document Level API issue

[beccahughes]

We had a Web Media F2F meeting with Apple, Google, Microsoft and Mozilla attending. We discussed this API and this issue is a follow up from that.

The document has an autoplay policy which can change. There will be an API on the document to get the autoplay policy and another on the media element which will return a boolean as to whether the media will be able to autoplay.

There are four types of autoplay policy:

• allowed - autoplay is allowed
• allowed-muted - muted autoplay is allowed
• disallowed - autoplay is not allowed
• unknown - document level autoplay is unknown, so we should use the API on the media element instead

There were two different options for the document level API which are described below:

Option 1: Sync API

The first option is for a completely synchronous API. AutoplayPolicy here is an enum of the different policies defined above.

partial interface Document {
  readonly attribute AutoplayPolicy autoplayPolicy;
};

Pros:

• It's clean and simple
• Information is available right away and does not delay the decision process for authors

Cons:

• It limits browsers to what they can do to calculate the autoplay policy. For Chromium, we would like to do a cross process lookup here to check in a file whether a site can autoplay. In order to to this synchronously, UAs would have to pre-compute and send these bits of information along with the other information that are per origin and sent along on a page load. This could potentially delay the loading of the entire page.
• Potential resource overhead since browsers need to do this check before loading the page

Option 2: Promise API

The second option is for a promise based API. AutoplayPolicy here is an enum of the different policies defined above.

partial interface Document {
  Promise<AutoplayPolicy> getAutoplayPolicy();
};

Pros:

• It does not limit browser implementations of what determines autoplay policy
• The browser does not need to calculate the autoplay policy until getAutoplayPolicy is called

Cons:

• It's more complicated than (1)
• It allows UAs to do slow things to determine whether auto-playing is allowed, and can therefore delay the start of the media (time to playback)

--

It was decided at the meeting to ask TAG for their opinion on which option would be suitable.

[padenot]

Sorry for the delay, here are a few questions, and some amendments:

• I was under the impression that Option 3 was dismissed during the F2F, I'm a bit surprised to see it here.
• The event listener should be removed from Option 1, for the reasons mentioned later in the issue. No supporter from Option 1 want this event.
• I'd have added the mention:

• Information is available right away and does not delay the decision process for authors

after:

• It's clean and simple

• I'd have replaced the mention:

• We cannot really do this if the API is sync.

by something like:

• In order to to this synchronously, UAs would have to pre-compute and sent this bits of information along with the other information that are per origin and sent along on a page load.

• I'd have added, after

It's more complicated than (1)

another point, along the lines of:

• It allows UAs to do slow things to determine whether auto-playing is allowed, and can therefore delay the start of the media (time to playback).

Specifically, those two last points reference the priority of consituencies, which clearly states that things that are better for the end user (second point, faster time to playback) of the author (first point, reading an attribute is always simpler than chaining a promise) take precedence over the difficulty of implementation (or the difficulty to spec things, which does not really apply for us here).

[eric-carlson]

Like Paul, I thought we agreed that:

• Option 3 is overly complex and should be dropped
• the event listener should be removed from Option 1 for the reasons you note in Event Listener Issue

[beccahughes]

Okay thanks! I have made these adjustments in the issue description

[beccahughes]

Historically, sites could detect whether they can autoplay by calling play and then immediately checking paused e.g

video.play();
if (!video.paused) {
  // we have autoplay
}

Now with the play promise sites can check whether autoplay is enabled if the play promise is rejected with NotAllowedError. Some sites (e.g. https://github.com/video-dev/can-autoplay) even load a tiny audio/video clip to detect this.

video.play().then(
  () => // autoplay,
  (e) => {
    if (e.name == 'NotAllowedError')
      // autoplay blocked
  });

We believe having the async API here for autoplay detection would bolster the play promise and move away from a synchronous model.

In addition, this has also caused us performance issues because we have to load in memory all the sites that can autoplay to know this when a page is navigated to.

[jernoble]

We believe having the async API here for autoplay detection would bolster the play promise and move away from a synchronous model.

This begs the question. A sync API would have the same benefits, and it's not evident that moving away from a synchronous model is useful for web developers.

In addition, this has also caused us performance issues because we have to load in memory all the sites that can autoplay to know this when a page is navigated to.

That Chrome has chosen to implement an API in a way that causes performance problems in Chrome is not a valid reason to impose a design decision on that API. The priority of constituencies places costs to page authors over costs to UA implementors.

[beccahughes]

This begs the question. A sync API would have the same benefits, and it's not evident that moving away from a synchronous model is useful for web developers.

For developers, the difference between the sync API and the async one is the matter of an additional await call.

That Chrome has chosen to implement an API in a way that causes performance problems in Chrome is not a valid reason to impose a design decision on that API.

It is not necessarily up to how we have implemented it but what it is doing. If we were showing a permission prompt then it would make a sync API nearly impossible but the answer should not be "well then don't do that". The API does not define what a browser should do so we shouldn't limit that.

[jernoble]

For developers, the difference between the sync API and the async one is the matter of an additional await call.

That requires developers who were not already using async functions to adopt them. It is arguably not a large cost, but it is a cost.

It is not necessarily up to how we have implemented it but what it is doing. If we were showing a permission prompt then it would make a sync API nearly impossible but the answer should not be "well then don't do that". The API does not define what a browser should do so we shouldn't limit that.

If a permissions prompt was necessary, there would be a "prompt" entry in the AutoPlayPolicy enum; checking the policy itself would never need a permissions prompt, and it could indeed be synchronous.

[alastor0325]

Close this issue because we had already decided to use sync API by previous all discussions.