search

WICG / interventions

A place for browsers and web developers to collaborate on user agent interventions.
Other
176 stars 28 forks source link

Block Web Audio autoplay on cross origin iframes #28

Closed mounirlamouri closed 8 years ago

mounirlamouri commented 8 years ago

Following up the recent changes in autoplay for muted videos on mobile, we would like to start an intervention and block Web Audio autoplay on cross origin iframes. The usage of Web Audio on cross origin iframes on mobile seems small enough to not be a significant Web compatible risk (based on Chrome Android data) when weighted with the use cases of using Web Audio in third party content.

In order to improve Web compatibility, the interventions will follow the current behaviour of Safari on iOS.

In the long run, we would like to make the Web Audio API aware of these restrictions, see https://github.com/WebAudio/web-audio-api/issues/836

Future work should allow pages to allow their third party content to autoplay or control autoplay behaviours. This could apply to Web Audio in addition to media elements.

dglazkov commented 8 years ago

Would there be a way for the developer to know that they were blocked?

RByers commented 8 years ago

Would there be a way for the developer to know that they were blocked?

That's the issue being discussed in WebAudio/web-audio-api#836. While API changes are being debated, perhaps the interesting question is whether we should document/match the mechanism already present in Safari (monitoring the 'state' etc.). Without digging into the details my intuition is that we probably should (since developers may need to write code to check for this in Safari already).

mounirlamouri commented 8 years ago

Web Audio now integrates a notion of allowed to start in the spec, see: https://webaudio.github.io/web-audio-api/#dfn-allowed-to-start

Also, change is: https://github.com/WebAudio/web-audio-api/commit/71facf007cc3bca5055a372f7998db3c40f9f829

RByers commented 7 years ago

First shipped in Chrome 55