Chrome updated to temporarily remove the autoplay policy for the Web Audio API

I think sites should simply have to ask for audio permissions like they already do for camera, location or microphone.<p>The browser trying to figure out if I intended to play audio is way too error prone versus me just asking.<p>I work on an audiobook player as a developer have been fighting this junk on iOS for years, it’s nothing but trouble. If I could just secure a permission to play audio worry free it’d make my life so much easier. Right now we need to ensure that all our audio is triggered by a click event, and if it gets too many steps away from the click event itself, everything breaks. It’s literally defined and limited how we can abstract our code.

Currently they&#x27;re saying:<p>&gt; The policy will be re-applied to the Web Audio API in Chrome 70 (October). Developers should update their code based on the recommendations at: <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;updates&#x2F;2017&#x2F;09&#x2F;autoplay-policy-changes#webaudio" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;updates&#x2F;2017&#x2F;09&#x2F;autoplay-p...</a><p>This is wrong and really needs to be reconsidered. Nearly all of the examples of broken webpages on that thread are write-and-forget games, which will never be updated; this plan would break them permanently, just to save a little engineering effort in Chrome.<p>The solution is simple: display a permissions request, like there currently is for camera, location and microphone. That&#x27;s how it should&#x27;ve worked in the first place.

This was a really awful change. Not only did it break lots of existing sites, it broke lots of sites <i>that weren&#x27;t even trying to autoplay</i>.<p>Basically the new policy triggered based on how you set up your AudioContext, regardless of whether you played any sounds. Most sites doing anything interesting with WebAudio just set up their context at init time (until now there was no reason not to), so as a result almost every WebAudio demo out there got broken. I was looking through back issues of Web Audio Weekly and in Chrome it was a wasteland - nothing worked, autoplay or not.<p>I know the Chrome team works hard, but sometimes it&#x27;s hard to believe that they feel the responsibility of stewardship they have over the web. Breaking existing content with no benefit to user experience should be considered a showstopper bug, not something you just delay until &quot;after developers have time to update their code&quot;.

It&#x27;s pretty ridiculous that Chrome has a whitelist. This should be enough of a red flag something isn&#x27;t right.

Whew, that&#x27;s a relief - until October when the same policy will be applied in Chromium 70?<p>As many are pointing out in the issue thread, I hope they figure out a solution that doesn&#x27;t break countless existing sites, apps and experiments (including their own, such as <a href="https:&#x2F;&#x2F;musiclab.chromeexperiments.com" rel="nofollow">https:&#x2F;&#x2F;musiclab.chromeexperiments.com</a>) using the Web Audio API.<p>I&#x27;m also not happy about the whitelist, and suspicious of the new Media Engagement Index.

Somehow no one comments that Chrome team rolled this out in the first place, and only then went and started asking for examples of broken sites. Even though their own websited like ”Chrome Experiments” are broken by it. Even though it would take QA a total of few hours to come up with dozens of broken sites.

What is the easiest&#x2F;best way to completely disable any auto-play for videos until I click on them? When I want to watch a video I&#x27;m happy to click on it to watch.

Chrome needs to ditch this whitelisted exception for &#x27;the top 1000 sites&#x27;. This is a barrier to every new video platform that wants to compete with YouTube or Facebook.

I actually agree with the motivations if not the outcome.<p>Here&#x27;s a maybe dumb suggestion. Make make a new API. Sites using the old API will get a blocking dialog. Sites using the new API will get the desired behavior. That way old content is still accessible.<p>Maybe `new AudioContext2()` or `new AudioContext({version: 2})` or `new AudioContext({optIntoNewBehavior: true})` where old behavior pops up a modal dialog?<p>Just throwing out ideas.

This is terrible. Chrome responded to a major breaking change by simply... delaying it? The exact same problems will be faced come October.

Why listen to developers? They (and their bosses) created such a hostile environment for users in the first place, if they&#x27;d done the right thing then this wouldn&#x27;t need to be baked into the browser at all.<p>Listen to users, they need protection from developers.