Issue 684890  has been merged into this issue.

I know the balance is hard to find about interventions. I appreciate your efforts to reduce these annoyances we sometimes have to endure on the web. That said, I want to point out that this intervention, as the similar one for web audio, is preventing some legit use cases. I'm trying here to bring some other ways of dealing with the problem.

First, some context: my web application is a video mixing application. It uses a pool of cross-origin iframes (of embed video player ala YouTube, Vimeo etc) to preload videos and then cross fade them. This intervention forces the user to click to start each video, making my app useless. I can't find a way to gracefully include this limitation in the user experience.

If the behavior was a little bit different though, something could be possible. Let's say only the first video loaded from a particular domain requires a user gesture. Then, any other video from the same domain can auto play. With this, I see how I can offer a acceptable UX. Another way could be for my app to ask for a permission, like it exists for geolocation or push notifications (cf https://w3c.github.io/permissions/#permission-registry), to autoplay videos.

So, is the behavior of this intervention set in stone? What do you think of the solutions I'm proposing?

I agree with the previous comment: While this is largly a good thing there can be some cases where a web developer intends for the primary content on the page to be a cross-origin iframe.

Changing the spec would defeat the purpose. For instance, adding an "allowautoplay" attribute to the iframe element would be abused. Advertisers would require publishers add the attribute and this bug's purpose would be nullified.

I agree with asking permission from the user so that they can decide if they want to allow autoplay to occur (with obvious checks for abuse - such as having many iframes on the page all requesting autoplay or a dynamic script that produces many iframes to flood the user with requests).

@jimbo2 the "discussion" is actually happening there: https://bugs.chromium.org/p/chromium/issues/detail?id=715049. I recommend reading the linked doc. Seems like mlamouri@ is taking care of crafting a proposal that is sensible and unifies the desktop / mobile world.

This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge

Marking as untriaged since the status is assigned but no owner.

This will likely be closed if and when the unified autoplay policy has launched. Keeping it open for now though.