New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 840866 link

Starred by 233 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Allow audio to autoplay, but optionally mute output

Reported by, May 8 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36

Steps to reproduce the problem:
Autoplay restrictions on the web have long been inconsistent and served only to impede legitimate use cases. Now Chrome 66 has transferred the restrictions to desktop, a lot of content is needlessly broken.

I've described this in detail in the following blog:

What is the expected behavior?
Allow audio playback on page load without any user interaction. Just mute the master output, and unmute it on the first interaction, or when whatever other heuristics deem it OK to play audio.

This still doesn't allow audio to be heard on page load. It does not relax the restrictions at all. It doesn't make it any easier to abuse audio playback. It just means there are no code changes necessary and existing web content keeps working.

What went wrong?
Web content should get audio playback with automatic unmuting by default, and opt-in to queuing audio until the first input event. Instead they are broken by default and have to opt-in to getting any playback at all. This makes no sense and has caused a lot of unnecessary breakage on the web. It also makes it unnecessarily difficult to get audio playback to work at all.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 66.0.3359.139  Channel: stable
OS Version: 10.0
Flash Version: 

Abusive content will just blare out audio at the first opportunity. They already can do so in that first user input event. All other restrictions only impede legitimate use cases. There is no reason to require legitimate developers to jump through hoops to get playback to work. The unmuting approach can already be implemented in JS land, but it requires extra complexity to implement a queuing system. If the browser does it, it's backwards compatible with the vast amount of existing web content, and removes the extra complexity from future JS developers.
Showing comments 63 - 162 of 162 Older

Comment 63 Deleted

Comment 64 by, May 10 2018

Playback on my website at is broken. Even after clicking for songs, I get an error "Uncaught (in promise) DOMException: play() failed because the user didn't interact with the document first.". The error message is false, because playback doesn't work even after user interaction.

Playback at fails with the same error.
This website was broken by the recent changes:

Comment 66 by, May 10 2018

Google's search page timer functionality also breaks due to this change:
Almost every PICO-8 game published on the web have been broken by the recent changes: e.g.

Comment 68 Deleted

"Can you please provide more concrete links to sites that are affected"

Here's my site:
An example from the site:
It's all free html5 toys, some were made with Emscripten+SDL1 and some were made with a Nim+TypeScript+WebGL+Tone.JS stack. *All* of the pages on the site are broken by this change (if you followed a link from outside the site to get there, the page is permanently silent, the sound never starts).

There are some things about this site that I think are interesting in context of this change.

1. Most pages on the site are noninteractive animations

I'm basically making WebGL movies. Most of the pages have a DOM that consists entirely of one canvas element, and don't have *any* event code. Some of the pages are extremely short. A couple of them would have their code potentially nearly doubled by the requirement to add interactivity just to generate an event to enable WebAudio permissions.

2. I tend to link the pages directly from off-site

If you visit the links above in Chrome 66, you'll find something interesting. If you visit first, then click on one of the animations, you get audio. If you visit the moiresea animation directly, no audio. The way I mostly use my site is I link the pages directly on Twitter, so this impacts my main use case. The way it worked before Chrome 66 is I have a Twitter card for each page, previewing the animation; if the user clicks on the card, they are taken to my site and animation starts immediately. In Chrome's new world, I'm expected to set things up where they click my twitter card, then click a second popup DOM element to get audio, then they watch the animation. That is kind of awkward.

You might say that the user might not want audio, so it's good that I have to throw up this DOM popup to confirm they want audio before showing the animation. But there's something interesting here. Let's say that instead of posting my animation as WebGL, I recorded it somehow and posted a 5 minute video to YouTube. In this case, if the user clicked from Twitter to the YouTube video I had posted, *the video would start playing immediately, whether they wanted sound or not*. In other words, this policy change by Google is essentially punishing me for hosting my movies on my own website instead of on YouTube. That is very weird.

3. The first five seconds of sound are important

Again, these are WebGL movies. Several of the animations on the site begin with sounds in the first few seconds which are interesting and are not repeated. This means a solution where tabs start muted and the user takes action to unmute them won't work great for me. One way or another I need a solution where the animation itself does not start until the audio permission issue is resolved.

Based on all this for my personal site's use case, the ideal solution would be if there were an synchronous popup like alert() or prompt() that allows me to request audio permissions. This would mean I could detect a chrome user, halt the page load to display the synchronous popup, have (or be correctly denied) WebAudio permissions by the time the AudioContext is created, and I would not have to rewrite my actual app code. If somehow I could in this process request to acquire a site permission, so that the next time someone visits the page, that would be even better.

One more note. As Google seeks a solution to this, it would be ideal if they could work through the web standards process. Right now you have to add browser-specific workarounds for both Safari in order to get sound on a fully standards-compliant WebAudio app, and Firefox is likely to add a third path at some point. The standards process exists to avoid this exact situation. Google should work with Apple and Firefox to modify the standard so it anticipates the existence of autoplay restrictions and gives app developers a set of steps we can follow that allows us to play sound on all of these browsers with one code path.
This broke our recently released social WebVR product
It also broke the automated bots we use via puppeteer to test the product.

Comment 71 by, May 10 2018

I had to update ALL the WebAudio examples from the MOOC HTML5 Apps and Games at, that gets several thousands of students. I got tons of messages in the forum complaining that the examples stopped working. I also use WebAudio on multiple examples of the "Multimedia" chapter on another MOOC at (HTML5 coding essentials). For my research purposes I also developed several WebAudio apps such as or or that stopped working. I had to update a multitrack WebAudio player at too....
YouTube iframe API doesn't provide a way to tell that autoplay failed.
If you embed a youtube video on a website and use the javascript api to play it, you have to play it muted because there is no way to tell if user interaction is needed or not.
There is a separate issue tracking WebRTC-impacted pages here: Several large WebRTC pages are affected, amongst them Google Meet, Hangouts and Chromebox for meetings. Services based on Tokbox, Jitsi and Twilio are also affected.

Our own service Confrere ( has problems playing back interface sounds, such as incoming call sound, new user entered waiting room etc. I suspect this is true for other applications as well, especially chat applications.

With this change Google are basically saying "forget about apps on the web". If we can't even have simple things such as interface sounds to help give notice on events changing in the background, then what's the point?
There is a separate blog post detailing impact on WebRTC services here:
My tool was broken by this. It's worth noting that the site never even plays sound, only uses an AudioContext to show a volume meter so the user can check their microphone levels.

Comment 76 by, May 10 2018

I think, given that the product manager ( claims that they didn't intend to break all these projects - and given that such a huge range of sites is affected, including many of Google's own pages - it would be appropriate to recall this version of Chrome while a more permanent solution is discussed. 

My reasoning:
1) On the one hand, the clear lesson from this debacle should be that developers need to be be consulted properly (rather than just informed via an edit to a single blog post) before shipping a change to Chrome that breaks websites. 

2) But 1) implies you can't just rapidly ship a fix, since you'll risk doing even more harm if you do not consult people properly about the fix.

3) Yet, you can't possibly leave this bug in place for much longer. You are doing real harm every day to people's businesses, including Google, harm to students and harm to artists and game designers, not to mention the giant pile of cultural work that is mangled by this change. Forcing people to wait while you decide what to do would be wildly unethical.

4) The only ethical option right now is to revert the change. You should do that immediately.
While I don't have a link to share I run a small (few thousand) network of kiosk devices that I can't upgrade to the latest chrome else our companies app will cease to work. We've had to hold back chrome in the past due to regressions in Linux video drivers but this is a new precedent.

Comment 78 by, May 10 2018

The interactive documentary "Criers of medellín" has its intro broken also 
The web sample editor is broken too.
Current Condition, a non-interactive art piece, loses sound in the current version of Chrome.

Momo Pixel's Hair Nah — a web-based game featured in Vice, Rolling Stone, The Cut, Teen Vogue, Fast Company, Slate, CNN, Mashable, Newsweek, Polygon, Fader, Essence, Mic, and Allure, among many other publications — no longer has audio in Chrome.
Any site that used audio as complementary to the intentionally-interactive experience. For example, Maine Office of Tourism make the "Maine Quarterly," which are interactive editorials/experiences. Here's the most recent one:

The web is something people experience in more ways than just visiting crappy media outlets that autoplay video and this change make little logical sense regardless.
Also broke :

Sound does not play on homepage

Comment 89 Deleted

Comment 90 by, May 11 2018

This has broken notification alerts for the chat tool Flowdock:

Adding a UI element to engage with to enable sound doesn't make sense since the notification alert is based on other people's actions, not the current client's. In other words, there is no "play" button.

This is crippling for any chat tool that isn't on the whitelist of sites that get autoplay enabled by default.

This musically-augmented article from Google which is featured at the bottom of my New Tab page today is partly broken by the current autoplay policy:

I say "partly" because the sound is only blocked as long as I scroll through the page with the wheel on my mouse (I presume that's also the case for scrolling through with a touchpad, though I don't have one on the desktop machine I'm currently sitting at).

However it appears that a key press or a mouse click anywhere on the page is enough to allow subsequent playback to start, and that includes all of the ways I more commonly scroll through webpages (especially long ones like this) - with the keyboard, the scrollbar, or with a middle-button 'autoscroll' that is provided by an extension that I installed.

The most common place I encounter unwanted autoplaying video is on news websites. How long before the inconsiderate ones adapt to use the same trick as this Google article and retry their audio-starting attempts on every click or key press, thus catching a proportion of users like me who were only trying to scroll down the page anyway? For me, the situation is not much different from where we started, except that we're now all poorer for the good stuff being caught in this crossfire.

Comment 92 by, May 11 2018

I'm not affiliated with them, but I was looking at and they have a background autoplaying video that doesn't load under chrome. It plays no sound, but this change broke the site nonetheless. 
You really should change the behavoir. I own a site with lots of html5games. All of the old games are broken, especially where developers will not fix it anymore. Which is the case in 85% of the time. You should change the audio policy to work for html5games. First you kill flash than you lower the quality of html5games with that. How should a site ever compete with the games in appstore nowadays?. Change the behavior so that the sounds will start when a user interacts with the page afterwards. Instead of killing it completely. Mute it to 0 or so and if a user interacts "clicks" within the game the sound is back. Or something similar. But it can't be that 1000 of games need updates and fixes because of your changes. Change it in a way that they haven't to be re-coded all!

It's really unsatisfying. First kill flash than use a standard which breaks the user experience of the games. What happens if you kill a Javascript function in the future which is used by many html5games frameworks. Will these games be broken than. Very bad company policy. More and more unsatisfied with Chrome and Google.
One more thing: Almost every game has an mute/unmute button on the game itself. But you don't even interact to that. If it would resume after you clicked it twice or something like that. But the behavoir is: If you didn't click anything before the audio is loaded you can never resume it with simply clicking.

Comment 95 by, May 14 2018

> Can you please provide more concrete links to sites that are affected by the recent audio automuting policy change? Thanks.

Although this is just demo content, it's representative of games use-cases:

the whole experience is muted.

Comment 96 by, May 14 2018

Guys, it's been a week. Can you please provide some kind of update on how and when you're planning to address this problem? 
Seconding the call for an update. I'm really hoping that breaking critical components of a huge swathe of web art and history is not going to stand, as I'm reasonably sure that wasn't the team's intent.

Comment 98 by, May 15 2018

My recommendation would be to allow the user to click the speaker icon in the tab (which is crossed out by default) then the audio resumes when they click it.

Comment 99 by, May 15 2018

Another case that may have slipped under the radar: gamepad controlled games never have a user gesture, since they rely on a polling API rather than firing events. This means gamepad-controlled games are now permanently muted even when the user interacts with them via the gamepad. You have to reach for the keyboard and press a key to unmute it, making it an awkward experience to play web games via gamepad.

I also filed this over 3 years ago for gamepad-controlled Android games in issue 454849, which still does not appear to be resolved. Now it applies to desktop too. It appears the gamepadconnected event may count as a user gesture in future, but I have never seen anybody even consider this point, and it's another event that must be specially-coded in to ensure audio playback is unmited, so it seems a particularly easy one to miss.

Comment 100 by, May 15 2018

Further to my previous comment, it appears these are the events we should attach to in order to unmute audio at the first opportunity:

pointerup, touchend, click, keydown, gamepadconnected

I am reasonably confident there are more, but it's not clear which they are. I have not seen any documentation or guidance attempting to answer this question. The list also has changed over time, e.g. touchstart used to work, but no longer does; it only works in touchend now. This confusion over when exactly web pages have permission to unmute audio deepens the problem by making it harder to completely work around, and easy to miss cases such as the proposed gamepadconnected event. Having just one event to listen to would be more reasonable (but still break a ton of existing content), but I think having to listen for an undocumented list of magic events is an unreasonable requirement and further demonstrates this hasn't been well thought out.

Comment 101 by, May 15 2018

According to, there is a new user gesture rule that counts when "any connected gamepad has a button more than 75% pressed" which can only be checked by regular polling. I think this shows how bizarre and complicated the rules around this can get!
wait for action from google.

its affect to my project. education interactive content for school. use html5 canvas and js.
Thank you everyone for the examples, they were helpful to our investigation.

We've updated Chrome 66 to temporarily remove the autoplay policy for the Web Audio API. This change does not affect most media playback on the web, as the autoplay policy will remain in effect for <video> and <audio>.

We’re doing this to give Web Audio API developers (e.g. gaming, audio applications, some RTC features) more time to update their code. The team here is working hard to improve things for users and developers, but in this case we didn’t do a good job of communicating the impact of the new autoplay policy to developers using the Web Audio API.

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:

This report was originally filed with a user interface suggestion for controlling autoplay. As others have pointed out, this is a non-trivial user interface challenge with a lot of nuances. We are still exploring options to enable great audio experiences for users, and we will post more detailed thoughts on that topic here later.
I appreciate that the Chrome team is taking this issue seriously and taking some action in response to the community's reaction to this change.

But simply delaying the enacting of this policy doesn't solve any of the major concerns that have been raised.

Come October, any existing software which utilizes sound and which is not or cannot be any longer maintained will be broken.

Additionally, these changes are not in the spirit of a free and open web, as Google controls the formula which decides which sites will be affected and which will not.

The primary job of a web browser is to support web standards. As it stands, Chrome is changing itself to *not* support web standards across certain blurry and arbitrary lines.

I agree that what Chrome is trying to do will be welcomed by some subset of users, but whether this feature -- which is going to break some of the most creative, interesting, fun and exciting parts of the web -- is enabled should be a choice a user makes knowing the drawbacks and benefits.

I would suggest *not* enabling this policy by default, and allowing a user to enable it by choice in Chrome's settings.

If Google is worried about what the adoption rate would be (since clearly users enabling this feature would help Google financially) I would suggest having some introduction to the feature upon loading up Chrome 70 (or whichever version) for the first time that says, "Welcome, Chrome has a new feature which will block auto-playing videos and sound. It may also impact legacy websites. Would you like to enable the feature?" Or something along those lines.
Either make it silent until the first user interaction 
OR show a prompt explaining the user what's going on.

Keep it the way it is is just nonsense and you guys know it.

And all websites must follow the same rule. 
ALL of them, otherwise it's not a standard, right?

Comment 106 by, May 16 2018

I also appreciate the revert, that was definitely the decent thing to do in the short term.

Unfortunately, the great majority of existing work will not be updated by October, or ever, and so we still face the effective cultural erasure of those works in October. You guys definitely have the power to break everyone's work, should you wish to exercise that power, but you do not have the power to make people add workarounds to code that they are not able to alter (for all the various reasons that have been given here). Nobody has that power.

"We are still exploring options to enable great audio experiences for users" does not read as a promise to do the right thing. If you are sincere in your claim that the side effects of the policy were unintended and unwanted, you should commit - in clear, straightforward language - to finding other alternatives which do not break vast swathes of cultural work that was developed and distributed on the open web.

Comment 107 Deleted

Whatever solution is arrived at for the October update, I strongly believe that it MUST:
-Provide the user some indication that the site is attempting audio playback
-Provide the user with the option to temporarily or permanently enable audio on that website
-Discard the double-standard media whitelist system where popular sites get to play by different rules

Otherwise, the pending update in October will once again irreversibly break well-behaved audio sites in a way that the end user will be unable to correct.

The fact is, most sites affected will not be updated on Google's say-so, and perhaps will never be updated at all. This may be because they're very old projects, or because the creators weren't aware of the change, or because those creators don't have the know-how to implement the needed fix. As such, you MUST give the user a way to override the policy and continue to enjoy "non-compliant" audio sites.

I'm glad you decided to roll back the WebAudio change. I think that given the primary target of the change was autoplaying video, you can afford to delay any changes to WebAudio while you seek the best solution.

It is dismaying however that, if I am reading the comment above right, your current plan is to re-instate the Chrome 66 policy rather than seeking a less disruptive policy. I believe Chrome *could* find a policy which accommodates developers while still protecting the principle users should explicitly authorize websites to play sound. The Chrome 66 policy on the other hand nearly seems designed to maximize disruption to both future and legacy software. Please reconsider. The delay you have announced is a great opportunity to get things right this time.

Above you say: "Developers should update their code based on the recommendations at:" Honestly, in my case I am not very likely to do this. I am much more likely to alter my page to redirect traffic to a warning page explaining that due to changes to Chrome my games require Firefox. This is because a browser-gate/redirect can be done by <script>-including one file, and accommodating the Chrome 66 policy means bespoke patching and recompiling seven separate web apps.

Fundamentally, delay or no, Chrome has decided they're going to implement AudioContext in a nonstandard way, and is now requiring developers to contort their architecture in order to get any sound at all. That is still not reasonable.
One more thing, you point us back to the page, but this page is *still* wildly inadequate:

- 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 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 I have to ask, at some point, are you going to proofread this page? Bits like "you’ll have to call resume() later when user interacts with the page" and "only when user interacts wit the page" are not valid grammar. This is a really minor point, but it does not make me feel confident that the Chrome policy is a product of carefully-considered thought when the public messaging about it contains glaring spelling errors.

I continue to think the Chrome should not be making this change, but *if* you are going to make a complex change like this it is reasonable to expect clear, useful documentation and developer tools (why can't I either query or change "autoplay permission" status from the Chrome Developer Tools?)
re #103:
Thanks for the relatively prompt revert. It helps a lot and hopefully a small silver lining here is that the temporary breakage alerted some developers to this change that would have otherwise not known about it until the breakage became permanent.

On to the negative part:
You state correctly that UI for controlling autoplay is "a non-trivial user-interface challenge with a lot of nuances", and say that you are still exploring options. Given that, the issue would still clearly seem to be unresolved, yet this revert is "temporary" and you have already determined when webaudio will break again, in October with release 70. If the issue is not resolved why is the revert not indefinite until the UX issues are resolved?

We all know and believe that the people behind the Blink audio stack, and Chrome as a product overall, are working hard to improve things for users and developers. We appreciate your apology for not communicating well about the new autoplay policy. However, for that apology to mean anything and for the intent of the team to come through, you need to improve on that, and right now the essence of the team's communication comes across as 'oopsies! we'll break it in october instead', which can't possibly be your intent?

At present this feels like a repeat of when Flash and Unity (separate events) were each shot in the head - for reasons well understood by everyone, but at dates set via some opaque process internally involving unclear stakeholders, and the dates were set in stone by the time it was possible for any end-user or even Blink developer outside of the inner sanctum to do anything about it. In both cases no good alternative was truly ready to replace the deprecated runtimes, and right now there is still no good solution ready for the problems introduced by this autoplay policy change. Is there at least a plan in place to introduce a comprehensive solution by October? If not, will the autoplay policy be deferred past October if the problem is not solved?

Many elements of the autoplay changes rolled out in 66 are still confusing and strange even after the revert, so if all of those are left intact when Web Audio breaks again in 70, it will still be a mess even if many games/apps have been updated. The MEI system is deeply confusing, the hard-coded whitelist feels unfair and arbitrary, and the actual process to debug failures around autoplay is a nightmare. It's confusing for both end-users and developers. Temporarily reverting the change is helpful but those issues need to be addressed by the time you break autoplay again as well.

Ultimately, this change needs a postmortem process, with the result disclosed (at least partially) to the public so that end-users and developers understand how this happened and know the general details of how it will be addressed in the future, because it's not the first time a project management failure of this magnitude has occurred in Chrome (or in Chrome's audio support, in particular).

Comment 112 by, May 16 2018

Can we please get some dialog from the Chrome team?

#103 above says "we reverted but will reapply exactly as is"

Why are none of the alternatives considered? #1 above points out that you could solve the entire thing by just muting audio until the first user gesture. That would mean no need for most apps to do anything or change anything.

Why is that not a possibility instead of just reenabling the restrictions in a few months? That seems like a great option as existing content mostly just works.

If that's not good enough, why not a prompt that allows the user to enable autoplay for the current site?

Comment 113 Deleted


Comment 115 Deleted

Comment 116 Deleted

Comment 117 Deleted

Also, we've mainly been discussing how the implementation should have been done, however I've came across this related issue that arrises from whitelisting some websites that don't have to deal with this issue. This is completely anti Net Neutrality

Comment 119 Deleted

#103 is not proposing any fix or solution, except to delay the issue by a few months.

I agree with comment #112 — can we please hear from the Chrome development team, and open a dialogue to work toward a better solution? Currently it feels like the issue is being triaged by a PR/marketing team with no care for the scope of the problem.

Comment 123 by, May 16 2018

I appreciate that you undid the change once you realized the damage it was causing, but it's disappointing that the solution to this "non-trivial user-interface challenge with a lot of nuances" still seems to be: thousands of developers who have been using the WebAudio API spec for years should change their code. I hope you really consider alternative solutions that don't break the web.

Here's a great section on the Google Developers blog itself about why you shouldn't break the web:
And that's from a situation where the developers whose code broke actually did something non-standard.

As it stands now, if someone develops a site *today* simply following the WebAudio API specs, Chrome will probably still break their site in October, unless they did one of two things:

1. Got lucky and happened to wire up the start events in a very specific way.
2. Got lucky and managed to find and correctly interpret a document that seems to only exist as a subsection of a 2017 blog post and is missing a lot of details. (e.g. what exactly does Chrome consider a "user gesture"? I read the page up and down and couldn't find a clear definition).

It's great that you acknowledge that you haven't communicated the policy well thus far, but you still haven't, so if you really must go forward with this web-breaking implementation (you shouldn't), please do take some steps to communicate this change to the wider development community that go beyond an edit to an old blog post.


Comment 124 by, May 16 2018

johnpallett@: This is totally bananas. You've not solved any of the problems, or even suggested how they might be solved. You also misunderstood my original report. I did not ask for any UI changes. I appreciate the revert, but this only provides some extra time until you do exactly the same thing, with largely the same consequences.

Here is a list of problems with what's happened and still aren't solved:

Problem #1: there is no point requiring code changes to unmute AudioContext. The browser could automatically unmute in the first user gesture. This does not enable any abuse and would probably have avoided the majority of the breakage. I explained this in my blog post that I linked to in the original report. I appreciate that this is a long and potentially confusing thread, so to emphasise this approach that you appear to have misunderstood and discuss it independently, I've filed issue 843555.

Problem #2: there is an undocumented, non-obvious, changing list of magic events that you need to listen to in order to reliably unmute audio. I've posted a suggestion for a "usergesture" event here to solve this:

Problem #3: it permanently requires all web apps using audio to implement a queuing system in case they try to play audio before the first user gesture. Combined with #2, this significantly raises the complexity required to develop reliable audio playback on the web, even when building new content with the restrictions in mind.

Problem #4: some input types, e.g. gamepad, don't yet count as user gestures. These can never be used to unmute audio. See issue 454849.

Problem #5: allowing autoplay for the top 1000 sites according to Media Engagement Index is an arbitrary limit. If the web doubles in size, will you double it to the top 2000 sites? Probably not. It unfairly advantages larger sites - and Google itself - and disadvantages smaller independent publishers. The fact there is an exception for the top N sites appears to imply there is value in allowing autoplay, or that the changes are indeed expected (or even intended?) to break websites and Google have decided to minimise this by only breaking smaller sites. This would be a very worrying attitude.

Problem #6: rather than trying to solve the above problems, Google is just going to wait a bit longer, then cause them again. It does not appear that Google is taking this feedback seriously yet. Google has a track record of ignoring other reports about this (e.g.  issue 280161 , issue 454849), has just misunderstood the original proposal, and still does not appear to be taking it seriously. When everything gets broken again later this year, will we have to go through this all again? Or will someone actually pay attention?

Problem #7: the fact UI changes are non-trivial has been brought up apparently as an excuse to avoid changing this. If it does require UI changes, shouldn't Google take the time to get this right before making the change, rather than breaking websites and telling web developers to deal with it? Is it that nobody can be bothered to do the necessary work so you're breaking websites as a shortcut? Has Google become that irresponsible with web compatibility now?

I invite a Chrome product manager to separately address each of the seven problems listed above.
I just wanted to add, because the rollback was not applied to <audio> tags, many WebAudio projects are still broken. Using <audio> is a standard way to stream audio tracks (MP3, OGG, etc) with WebAudio, so this rollback has only fixed a fraction of all sites using WebAudio.

Some examples of my own WebAudio projects which are still broken after the rollback:!/experience

Comment 126 by, May 17 2018

Anyone have some data that substantiates the theory that users want muted videos to autoplay by default (rather than, say, on a per-domain basis like cookie retention and "Clear cookies on exit" settings)?

It's entirely anecdotal (that's why I'm asking for data…), but everyone I know can't stand muted autoplay. Google didn't provide any reasoning or substantiation why "Muted autoplay is always allowed" in Advertisers and consumer-facing sites abuse that privilege by autoplaying muted unrelated videos.

Clearly some users want autoplay for some domains. My question is whether at least a meaningful percentage of users would prefer to disable autoplay entirely, even for muted videos, at least for some domains.

Related discussion:
we still have issues with our ebook application which uses some basic games templates with audio :-( We have 18 of 34 templates where the audio fails to autoplay and then disables some of the buttons. We have developers looking at the issue of our code but we would ask for the audio changes to be rolled back too please.
Would it be possible to at least inform the user what is happening when autoplay audio is blocked, and give the user the ability to override the block? 
Safari on iOS seems to have the same behaviour as the latest changes in chrome, except for one thing: the AudioContext automatically resumes when any connected AudioBufferSourceNode starts playing from a user gesture.

I believe implementing this same system would solve most issues.
The solutions proposed in issue 843555 sound good as well.

Comment 130 by, May 17 2018

Using the Safari iOS approach will have similar problems on desktop, because it still requires code changes. The mobile restrictions have been around pretty much since the implementation of these APIs so everyone just coded around them. The problem now is nobody did that for desktop since it always just worked, so introducing new restrictions will break a large amount of existing content.
I develop a commercial application, affected by this change. In anticipation of the release of Chrome 66 we had to change to having a start-up screen to workaround the new policy.

A general problem seems to be that browser policy is leaking into APIs and application design, burdening developers with a need to be intricately aware of corners of the policy. A real solution would separate policy from API.

It seems far better design to mute the tab but leave the web page seeing success as it makes API calls. Then prompt the user "this web page wants to play audio" allowing the tab to be unmuted (unseen by the web page)

This is easy to explain, with less API complexity and fewer states to deal with. It would eliminate the problem of the complex ordering of events that results when permissions checks are interleaved with everything else (see points 1,2,3 from comment #124)

The browser would then have an ongoing freedom to refine and adjust the policy where necessary at any time in the future.

In its current state the policy ends up intertwined into web application code. That's effectively a deadlock to future changes when along comes a new use case or a new category of device.

One corner that illustrates this: I could not create an AudioContext without a user gesture; yet on its own an AudioContext does not make sound. This proposal side-steps the delibrerating of arbitary choices like these on a case-by-case basis. It could also be a compelling design for microphone input, too.

Ultimately the end user only cares to stop antisocial audio coming from their speakers, so stop the audio at that point.

Is muted audio context going to be allowed?
comment #125 [0] is still broken because it uses <audio> element instead of Web Audio API.


Comment 134 by, May 21 2018

I work on a website, (embeds for 3rd party services such as YouTube and SoundCloud, both with autoplay permission delegated) that allows people to share music and listen collaboratively. We were also affected by this change.

Personally I'd like to have another permission we can request (like notifications) OR unmute on first user interaction as suggested many times before. The way blocking autoplay is currently implemented does not work for me.

My personal website is also broken (using <audio> elements).

Comment 135 by, May 23 2018

Just to reiterate, where can we get some official dialog from the Chrome team?

I think many of the chat apps have a very valid use case that is not addressed here. They need to be able to play a sound without a user gesture. Requiring a user gesture to start is not an option since they will often get launched in the background when chrome restarts. So they'll sit there, wanting to notify the user but with no way to notify them. Note: The user should not be required to turn on notifications (the Notifications API) as notifications have other issues (for example the message might be sensitive and the user does not want it to appear on their screen until they are sure no one is looking)

It really does seem like a permission dialog is a better solution. Then the person using the chat page can get asked "can we play sounds y/n" the first time they visit and subsequent times will just work even it lunched when tabs are recovered on chrome launch.

Comment # 135 has stated exactly the problem we face now. In our case, our WebRtc app waits for the incoming calls. If a call arrives, the app should play a ringtone. Mr. Google, your policy change has fundamentally broken the incoming call sound alarm mechanisms on the Android Chrome. After we "Add to Home screen", the <audio> still does not play. That has failed to fullfil your own design goals.

Please, someone, if you know a workaround, leave a message here.
The workaround for now is to use the WebAudio API directly. There is no other way unless an official clarification is made. 
This exception looks cold and harsh. Mr. Google, please have some tender pity for those visually impaired people. They must hear some short prompts delivered by the "play()" before they can start to interact with the document. Now, Chrome refuses to play before the interaction, and they cannot interact before the play. What a vicious cycle!

Uncaught (in promise) DOMException: play() failed because the user didn't interact with the document first.

I suggest you drop the entire autoplay policy concept. I propose something different. Since there are always good websites and abusive/malicious websites, the Google search engine should introduce sort of rating systems to blacklist those websites as soon as they are proven to be autoplay abusive. Just as we, as individuals, value our personal credit history, the websites should do so too. Banning a bad website from Google search results forever would be a very strong deterrence against bad behaviors. The approach would be beneficial to Google too because that will further strengthen the user loyalty to your search engine.

I am not suggesting you rate the websites politically, socially, etc. You rate them only if they misbehave technically, for example, abuse autoplay, full screen hijack, etc.

Comment 139 by, May 28 2018

Google has not even attempted to explain its approach to this issue. Perhaps it really is indefensible? They cannot justify the way they've implemented the autoplay restrictions in light of better alternatives. I would be happy to hear anybody pointing out any problems with my proposed solution, but there has been nothing said about it at all so far. What are we supposed to conclude from this?
 Issue 842455  has been merged into this issue.
Any updates on this? It's been nearly a month since we've heard anything at all.

I understand that policies take a while to craft but does that crafting process need to happen in complete isolation from developers?
Is there any official documentation anywhere as to how to activate an audio context in chrome after the proposed going back to the other behaviour?  I'd like to have the fix in as soon as possible in puzzlescript so that exported games made in the interim don't get broken anywhere, but I can't find out how to do it.

(/ yes, I'm still disappointed that the plan is to go back to the version that breaks the games internet)
The end of should provide the guidance to turn the policy back on for Web Audio.
@142 - when you are testing, note an additional change that just went out in Canary: If a node calls start() after a user gesture, then the associated audioContext will resume() if it was previously suspended by the autoplay policy. With this change, the majority of the sites listed above play audio after a user gesture.

That change is in the latest version of Canary, it’s one idea we’re exploring. We’re not sure yet whether this will be a permanent addition to the policy, curious to hear your feedback.

For your testing purposes the following command-line will force Chrome to block autoplay (including Web Audio, which currently isn’t blocked by default): 

chrome.exe --disable-features=PreloadMediaEngagementData,AutoplayIgnoreWebAudio, MediaEngagementBypassAutoplayPolicies

> If a node calls start() after a user gesture, then the associated audioContext will resume() if it was previously suspended by the autoplay policy.

This would be a large improvement over the current policy.

However, it still wouldn't fix sites like, who would need to gamble that the user will interact with the page before the timer goes off.

It also wouldn't solve the problem that MEI is only calculated for video/audio tags, which means that sites relying on webaudio can't be whitelisted, even manually by the user.

It's much better than the current situation, but hopefully isn't the only solution being explored.

Comment 146 by, Jun 18 2018

> If a node calls start() after a user gesture, then the associated audioContext will resume() if it was previously suspended by the autoplay policy.

Why not just automatically unmute the audio context in the first gesture?!
I found this "feature" and Google's response to be unfortunate. At least work with us devs. What would help me is giving us a chrome setting that my company can whitelist our internal web apps via global policy.
Components: Blink>WebAudio
October (when the behavior is due to be reintroduced) is now only one month away. We still haven't heard anything.

Back when this whole issue initially started, I talked to devs on the Chrome team on Twitter and I had them assure me that this was just a communication issue, that internally everyone at Google cared, that it was just that solutions took time.

But... we're still in a position where no one from the Chrome team is talking to the developer community. And while I don't doubt those people's intentions or sincerity, it doesn't look like the team has learned anything or gotten any better at working *with* devs. Even if there are changes to the policy incoming, one month isn't enough time to talk to people about them. We're in the same exact position now that we were then.

What was the point of delaying the update if the Chromium team was still going to put devs in a situation where they wouldn't be able to prepare for the change?

When the original response was posted, more cynical devs interpreted it as a veiled way to say, "Fine, we'll back off until you stop complaining." The cynical take on the web was that all of the posturing and vague answers about looking for solutions was just a passive aggressive way for Google to tell devs to shut up and stop complaining.

Please don't prove those people right.

It would make this situation so much better if anybody from the Chromium team, at all, was willing to just talk to devs. Explain why the solutions people have brought up here are bad. Explain why Chrome is making these choices, or what the process was that led to them. The solution or reasoning doesn't have to be perfect.

It's the silence that really says, "Chrome does not care about developers."
Just to sort of reiterate a few of the things we still don't know:

- Both Firefox and Edge have stated that they'll have explicit controls for a user to override autoplay status on a site-by-site basis, regardless of whatever their internal algorithm is. We don't know if Chrome will have those controls.

- Both Firefox and Edge have stated that they'll have user-visible indications when autoplay is blocked. We don't know if Chrome will have an indication.

- We don't know what went into the decision to block autoplay instead of muting tabs, especially since malicious sites can detect stopped videos and use clickjacking and Javascript popups to force visitors to trigger a user action.

- We don't know how MEI will work with Javascript audio APIs, given that it's calculated based on user play statistics, which the audio API will never be able to trigger.

- We don't know why autoplay is allowed when navigating within a domain.

- We don't know how (or if) Google plans to address concerns about neutrality and anticompetition with MEI scores that favor already established players and services. We don't know what went into the decision to make the pre-populated MEI list private.

- We don't even have a fully documented list of what constitutes user actions.

There is just a lot of stuff we don't know.
> Why not just automatically unmute the audio context in the first gesture?!

It seems like the page announcing the policy ( was once again silently updated with a significant change - in this case, changing the target version from m70 to m71. The code for the page shows it was updated September 27. 

One major problem with this whole policy debacle has been that the audio stuff was never announced, but silently added to that video autoplay announcement without any edit history or further announcements. And now it seems the date when the policy goes into effect is also a moving target, and changes in the date are not announced but again silently added to that one blog post.

It's obviously not reasonable to expect developers to sit and monitor a 2017 blog post  as their main way of getting critical data about how Chrome is going to work with their games and websites. I strongly suggest that you folks in the Chromium team need to get more transparent about what you're doing, when you're doing it, and why. Even if you're unwilling to seek developer input before formulating and deploying your policies, you could give us half a chance of adapting our new projects to work with your forthcoming versions if you would just announce the breaking changes in an honest way.

Comment 153 Deleted

I can't even get the flag to properly deny autoplaying audio reliably. This is such a terrible policy change for no apparent reason. Google is basically trying to shove policy because it's the dominant market.

Just thought of a situation which this is trying to prevent. Most websites with autoplaying videos automatically have a popover or modal show up before you can see the content of the page. Wouldn't clicking that automatically let them autoplay the videos which we didn't want to see?

I don't know if this actually removes the issue but actually makes it worse, almost every website will have a modal popup to gather your email or have you register just so they have some gesture to start playback.

Not only will the autoplaying still happen, but now more and more websites may default to having a modal just so they can bypass this autoplay restriction. If you specifically try to combat this all you're doing is making it more difficult for legitimate use, I switched to firefox to see if they have any autoplay restrictions and it appeared they're going the route of every other single access feature chrome does (i.e. location info, webcam, microphone). Is it just not possible for the Chrome team to approach it that way? Is there a specific reason as to why it has to be user gesture? This would eliminate all of the extra work to update existing websites which are no longer maintained.

As someone mentioned before (, as great of a feature this is I feel there are ways to move forward that don't break every single website. Is this a user experience issue? Does the tooltip asking for autoplay permission too strongly break application flow?

I can't reliably find any reason for why Google is approaching this problem with this solution. Let alone discussion with the community. What better group to ask than the people who develop for it.
Three weeks to go, and it's still totally unclear what the policy is going to be and which websites will be affected. No communication at all from the Chromium team since June. 
Hi everyone,

I'm Brendan - a PM now working on Autoplay in Chrome.

We have an intent-to-ship thread in the blink-dev group (!msg/blink-dev/5Y1BqbGauEs/rRocaytKBgAJ) where we've been discussing the upcoming policy for Web Audio, and the metrics we've been using to evaluate the impact.  Apologies for not linking this bug to the thread previously.

In addition, we have new documentation coming soon to various blogs, and I'll post links to those as they come online.

Definitely email if you have questions after you've looked through the I2S thread?

Comment 158 Deleted

Good job getting that documentation available before the feature launched <_<
To update the questions from my previous comment:

- We now know that there will be a way to disable the policy globally. We don't know if there will be a way to disable it on a page-by-page basis (presumably not).

- We still don't know if there will be a user-visible indication that autoplay is blocked (presumably not).

- We know a little bit about what went into the decision to block autoplay instead of muting tabs (allow websites to know whether or not they were blocked, try to influence future site design, copy Apple). We don't know why it's important for websites to know whether or not they're muted (presumably Google will eventually get rid tab muting entirely then?). We don't know what discussion was held about dark patterns like clickjacking to enable autoplay.

- We do know how MEI will be calculated with web audio APIs now, so props on that.

- We still don't know why autoplay is allowed when navigating within a domain. Presumably that would just break too much, but it seems to be a strict negative for actual users.

- We still don't know how (or if) Google plans to address concerns about neutrality and anticompetition with MEI scores that favor already established players and services. We don't know what went into the decision to make the pre-populated MEI list private. We at least have 

- We still don't have a fully documented official list of what constitutes user actions, although Google is at least now Working on It(tm).

On the blink-dev group, I don't see any indication that any external developers have actually reached a consensus with Google's approach. The vast majority of external input has been from Ashley (thanks!). Most of her input has been rejected, but some of it has been incorporated for the better.

On the whole, the situation is way better now than it was when the feature originally launched, and credit is due to the Chromium team for that. Where we are is a serious improvement over where we were. But it's still not great, and I echo Bennett's inputs that this is frustrating for anyone trying to treat the web like a serious gaming platform on par with native. The reason the web can't compete with native right now isn't because we don't have enough fancy APIs like Service Workers. It's because we can't trust the web to be stable with simple things like audio or controller input.

It's also frustrating to see Chromium developers on the linked thread phrasing this again as a debate over whether to prioritize users or developers, when much of the criticism has been that the current policy is kind of the worst of both worlds for everyone. As a user, I don't want audio to autoplay when I move within a domain. I don't want audio to start autoplaying when I highlight text on a page. And certainly, as a user I don't want pages to be able to tell whether or not they've been muted.

But at this point, I don't see any indication that anything else is really going to change much, and I'm tired of arguing about it. If the Chromium team sees fit to ship a feature with this level of debate, where pretty much everyone outside of Google who's weighed in on the thread is against it -- fine, it's your browser.

My policy is that if I have to rewrite code for any of my games to specifically support Chrome, I'm going to put a popup telling users to move to Firefox instead. I'm not relying on my games or apps for revenue right now, so I can afford to lose users who won't do that. I'm not going to do extra tech support for my users just because Google is stubborn.

I'm also going to avoid shipping any games that I intend to monetize as progressive web apps where possible unless I can bundle them into a single installable piece of software where I know exactly what browser version they'll run on. Electron is still a much more viable option for most web software than progressive websites are, precisely because of issue like this.

Comment 162 Deleted

Showing comments 63 - 162 of 162 Older

Sign in to add a comment