[TPAC 2018] Autoplay Policy Informal Meeting Notes

[beaufortfrancois]

For posterity, here are the notes of the Autoplay Policy Informal Meeting at TPAC 2018, October 23rd.

Attendees

• Jer Noble, Apple
• Scott Low, Microsoft
• Paul Adenot, Mozilla
• Francois Beaufort, Google
• Mounir Lamouri, Google

The outcome of this discussion is that we’d like an autoplay policy on document and a method on a HTMLMediaElement to know if autoplay will succeed.

It was discussed using the upcoming User Activation API (instead of the canAutoplay method) but since Apple folks are not sure to actually implement it, it was decided to not rely on this.

Disclaimer: names are subject to change

document.autoplayPolicy returns a enum string that can change overtime based on user session activity:

• “allowed” if autoplay is currently allowed.
• “allowed-muted” if muted video autoplay is currently allowed.
• “disallowed” is autoplay is not current allowed.
• MAYBE: “prompt” if autoplay will trigger a prompt (iif firefox decides to go that road)

HTMLMediaElement.canAutoplay() returns a promise that resolves if autoplay for a specific media element is allowed or rejects with some helpful error if not:

video.canAutoplay()
.then(_ => {
  // When muted videos can autoplay, it could be either
  // because the video is muted, or the video has no audio track.
  // It would also succeed if the call is during a user activation,
  // or if the video was previously played.
  // The video must have metadata loaded (readyState > HAVE_NOTHING).
})
.catch(error => {
  // If the video metadata did not load (readyState == HAVE_NOTHING),
  // or the call did not happen on a user gesture, or, when muted videos
  // are allowed if the video is not muted and has an audio track.
  // InvalidStateError will be used if the metadata did not load.
  // NotAllowedError will be used for all other cases.
});

Web Audio

Using the API for Web Audio would be as simple as:

const audioContext = new AudioContext();

if (audioContext.state === 'suspended') {
  if (document.autoplayPolicy === 'allowed') {
    // State is suspended only because hardware is slow.
  }
  if (document.autoplayPolicy === 'disallowed' ||
      document.autoplayPolicy === 'allowed-muted') {
    // State is suspended because of the autoplay policy.
    // TODO: Call audioContext.resume() after user gesture.
  }
}

Mozilla suggested to implement a new state called blocked, similar to the interrupted state implemented by Safari iOS. This state was meant to distinguish between suspended state caused by slow hardware and autoplay blocking. There was agreement that the document-level API was solving this use case (see above).

Autoplay Specification

In addition to drafting these changes, the discussions led to the creation of the wicg/autoplay repository in which a specification defining autoplay will be worked on. Paul Adenot was volunteered to author the specification :)

[mounirlamouri]

Because it's not mentioned above, I believe that document.autoplaPolicy should look like this:

partial interface Document {
  readonly attribute Promise<AutoplayPolicy> autoplayPolicy;
};

[jernoble]

Is there any precedent for a readonly attribute Promise? It seems really weird to have a resolved Promise for a value that can change over time.

[mounirlamouri]

I believe Service Worker does something similar for `ready`, see: https://www.w3.org/TR/service-workers-1/#navigator-service-worker-ready

…

On Tue, 20 Nov 2018 at 21:42, Jer Noble ***@***.***> wrote: Is there any precedent for a readonly attribute Promise? It seems really weird to have a resolved Promise for a value that can change over time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjAligSJxc54HnsckQkNFfZc6ZU-2Szks5uxL2CgaJpZM4X6Nkx> .

[cpearce]

Is there any precedent for a readonly attribute Promise? It seems really weird to have a resolved Promise for a value that can change over time.

Will spin this off into issue 6.

[tadas-subonis]

Can this have also an explicit permission request like notifications?

    if (Notification.permission === "granted") {
      console.log("We have notification permission");
      return;
    }
    Notification.requestPermission();

At the moment, the way autoplay blocking is implemented is breaking VoIP applications that are waiting for somebody to call and only then ring the sounds (w/o user interaction).

[mounirlamouri]

I think https://w3c.github.io/permissions/ is what you are looking for here. Though, I do not think we want autoplay to be exposed as a permission as I do not believe browsers are willing to allow websites asking for the permissions at the moment.

…

On Fri, 8 Feb 2019 at 12:30, Tadas Šubonis ***@***.***> wrote: Can this have also an explicit permission request like notifications? if (Notification.permission === "granted") { console.log("We have notification permission"); return; } Notification.requestPermission(); At the moment, the way autoplay blocking is implemented is breaking VoIP applications that are waiting for somebody to call and only then ring the sounds (w/o user interaction). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjAlg2fLTnqN9EiD7Y4bMx3jDrxx6hKks5vLbRHgaJpZM4X6Nkx> .

[tadas-subonis]

What I meant is that it doesn't have to be accessible ONLY through permissions.

At the moment, there are multiple mechanisms that disable the behaviour: https://sites.google.com/a/chromium.org/dev/audio-video/autoplay

Adding additional exception, when "audioapi" permission is granted would work perfectly. This way chat/voip developers will be able to request relevant permissions upon the start of the application, and it won't change the flow for the others.

[cpearce]

I think the WebRTC use case is separate and distinct from the annoying cases that browsers are mostly trying to block, and is probably only blocked because it passes through the same top level API surface; HTMLMediaElement.play().

Firefox allows sites which have been granted persistent camera and microphone permissions to autoplay, in order to permit cases like you're describing. Our opinion was that since the browser explicitly prompts the user for permission for the site to access the camera/microphone before a WebRTC stream plays, the user has clearly signaled intent to allow media on that site. Maybe you should file bugs with the other browsers asking them to implement the same exception?

[mounirlamouri]

Chrome and Safari both allow autoplay while a page is using getUserMedia. It seemed a bit better than only relying on the permission.

[a2sheppy]

Would appreciate a heads-up when a specification is available for this, as this falls into my bailiwick docs-wise.

[alastor0325]

Close this issue because this is just for some old discussion, and we already started editing a specification for Autoplay Detection API.