Autoplay Policy Detection API

[alastor0325]

Wotcher TAG!

I'm requesting a TAG review of Autoplay Policy Detection API.

Most user agents have their own mechanisms to block autoplaying media, and those mechanisms are implementation-specific. Web developers need to have a way to detect if autoplaying media is allowed or not in order to make actions, such as selecting alternate content or improving the user experience while media is not allowed to autoplay. For instance, if a user agent only blocks audible autoplay, then web developers can replace audible media with inaudible media to keep media playing, instead of showing a blocked media which looks like a still image to users. If the user agent does not allow any autoplay media, then web developers could stop loading media resources and related tasks to save the bandwidth and CPU usage for users.

• Explainer¹ (minimally containing user needs and example code): https://github.com/w3c/autoplay#readme
• Specification URL: https://w3c.github.io/autoplay/#acknowledgements
• Tests: https://wpt.fyi/results/autoplay-policy-detection?label=experimental&label=master&aligned
• User research: N/A
• Security and Privacy self-review²: https://github.com/w3c/autoplay/blob/main/security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/autoplay
• Primary contacts (and their relationship to the specification):
  • Alastor Wu (@alastor0325), Mozilla, Editor
• Organization(s)/project(s) driving the specification: Mozilla Firefox
• Key pieces of existing multi-stakeholder review or discussion of this specification: FPWD Horizontal reviews status https://github.com/w3c/autoplay/issues/30
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Firefox bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1813220

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We are looking to send an Intent-to-ship for Firefox within the next few upcoming releases (Fx111+).
• The group where the work on this specification is currently being done: MediaWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): MediaWG
• Major unresolved issues with or opposition to this specification: N/A but there was a privacy fingerprinting concern issue which has been closed but could be re-discussed if necessary.
• This work is being funded by: Mozilla Firefox

You should also know that this API was already implemented in Firefox, which is currently only enabled on Nightly channel and haven't been pushed on the Release channel yet. Safari and Chrome expressed the interest during the past discussions but haven't express an explicit timeline when they would start prototyping this spec.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[rhiaro]

@leaverou @cynthia and I reviewed this in our virtual face-to-face breakout today. We agreed that this will be a beneficial addition to the web platform, and delighted to see that there are multiple implementers interested.

We recall that in the past there was a disagreement about whether this API should be sync or async. Could you share how that was resolved in the end, or if there are any outstanding issues related to this?

We appreciate the quality of your explainer, and may add it to our list of examples of exemplary explainers. Thanks for the review request, and we look forward to seeing how you proceed with this work.

[chrisn]

Thank you @rhiaro @LeaVerou @cynthia for your review and positive feedback. Speaking as Media WG chair, the WG took on board at the time the TAG advice in https://github.com/w3ctag/design-reviews/issues/439#issuecomment-561902607 that a sync API is preferred. This is reflected in the current draft spec.