We currently do not have a concrete timeline for it, but it will be announced via https://www.chromestatus.com/features. Also I will update this bug when we made the decision.

Hi we use WebAudio same for a corporate media player which by its nature does require autoplay. Most of our clients use Android devices , will there be a way via chrome flags to disable this policy ? Please advise if that is not going to happen as we will probably have to discontinue supporting Chrome.

olaf.stelling@

Are you using WebAudio or audio element in your media player?

mlamouri@

Do you have an answer for #2?

mlamouri

We are using AudioContex.createMediaElementSource and then chain in gain and compressor nodes. We are actually using 2 of these chains going to the same audio output to deliver pre-emptive messaging as well. Currently we only support Chrome for web based delivery as Chrome has the persistent file system which we use to store audio locally as a lot of our clients are in areas were streaming would be too expensive and too unreliable.

Autoplay has been handled by mlamouri@, so reassigning this issue.

Note: There has been no movement on this bug, but since the last update the feature has shipped and documentation has been posted

https://developers.google.com/web/updates/2017/09/autoplay-policy-changes

Still doesn't answer all my questions though (for example what about createMediaElementSource …)

I have received no acknowledgement of my comments either here, or sent to the Twitter account, or on the other popular bug on this issue. So I would just like to reiterate my outstanding problems with the documentation from the other popular bug https://bugs.chromium.org/p/chromium/issues/detail?id=840866#c110

- The documentation treats <audio> elements and WebAudio as strictly separate concerns. This is not really the case, they can interact. For clarity, you should explicitly document the behavior of audio objects (eg new Audio()) and createMediaElementSource wrt autoplay.

- You should explicitly document what conditions enable use of WebAudio. The document says "user interacts with the page (e.g., user clicked a button)" and "the document received a user gesture". This is vague. Give us a list of qualifying events. Also, does "alert()"/"prompt()" count as interaction? If not, why not?

- The document near the top says: "Autoplay with sound is allowed if: User has interacted with the domain (click, tap, etc.)." What does this mean? In my testing with Chrome 66, it appears it means that if you click a link from one page on a site to another, autoplay permissions are granted until the tab closes and then are lost on the next visit. This seems to kind of suck as a policy (just because I clicked a link on CNN.com doesn't mean I want CNN to play a video) but you need to clearly document it. Does this magic work with anchor links? Does it work with javascript: links? If I trigger Javascript from a click to trigger location.reload() do I get to keep autoplay permissions when the page reloads?

Also there are flagrant spelling/grammar errors. I realize spelling errors do not objectively matter but it is a very, very clear sign that y'all are not putting effort into improving these docs. It could not possibly be hard just to jump in and add that missing letter "h", which says to me that you're not making changes at all right now for whatever reason.