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

Issue 835767 link

Starred by 89 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression

Sign in to add a comment

common AudioContext/getUserMedia pattern broken due to changes in autoplay policy

Project Member Reported by, Apr 23 2018

Issue description

Chrome Version: 66.0.3359.106
OS: (e.g. Win10, MacOS 10.12, etc...)

What steps will reproduce the problem?
(1) go to
(2) observe the bars while speaking

What is the expected result?
they move.

What happens instead?
A console warning is shown:
The AudioContext was not allowed to start. It must be resume (or created) after a user gesture on the page.
Props to QA for actually noticing this:

This breaks a number of websites, including google meet, that use AudioContext after getUserMedia to visualize the microphone level.

Adding autoplay-policy=no-user-gesture-required reverts to the old behaviour.

Is blocking AudioContext required when there is an active MediaStream which suggests a somewhat high level of trust?

Comment 2 by, Apr 23 2018

Components: -Blink>GetUserMedia Blink>Media>Autoplay
Labels: -Pri-3 Pri-2
Status: Assigned (was: Untriaged)

Comment 3 by, Apr 23 2018


Comment 5 by, Apr 23 2018

safari seems to have a policy to allow this if getUserMedia is on:

Comment 7 by, Apr 23 2018

There's a bunch of sites impacted by this bug. The user has already given explicit permission to use the microphone, but we still can't access it unless they click on something on the page every time they visit the page. 

Comment 8 by, Apr 24 2018

Labels: -Pri-2 Pri-1
Labels: OS-Chrome

Comment 10 by, Apr 24 2018

Labels: -Type-Bug Type-Bug-Regression
Status: WontFix (was: Assigned)
I can reproduce this on Chrome and it looks like we are blocking the AudioContext because there is no user gesture and Safari is allowing it because they allow AudioContext to play if getUserMedia is on.

The problem with the Safari approach is that they are simply allowing any AudioContext to make noise if getUserMedia is on. This is quite risky as it means that a website could potentially pipe any audio through that context.

Our autoplay policy has a number of ways to be allowed to autoplay which should be sufficient for WebRTC apps including:
 - Having a user gesture on the page. This is also passed through navigation so long as the page is on the same eTLD+1. Most WebRTC apps should be able to capture a user gesture here.
 - High Media Engagement. We have seen a number of WebRTC apps able to successfully achieve a high MEI score.
 - Apps, Extensions and Hosted Apps are all unaffected by the autoplay restriction.
 - URLs can be whitelisted for autoplay through Chrome managed policies.

Comment 12 by, Apr 24 2018

Let's discuss this better before jumping to wontfix. "Enable legitimate uses of autoplay without complicated workarounds" was one of the design goals.

Comment 13 by, Apr 24 2018

Status: Assigned (was: WontFix)
Agree with Huib.

Sorry to change the the status back like this, I would like for affected parties to be in agreement before we mark the bug as fixed/wontfix or decide on the next steps.
Thanks for reopening.

FWIW, Jitsi Meet is suffering from this, and one would think ir engagement
score is high enough, but that doesn’t seem to be the case for a fresh user
profile, resulting in a craptacular user experience.

As for gestures, if you use a full URL which includes the room, the user is
dropped directly into the conference, so zero clicks / gestures are
involved, so expecting one is also a flawed assumption, not every
conferencing service has a “hair check” screen.


Our recommendation here is to require a user interaction before playing. If these sites cannot autoplay because they don't have a gesture they should start in a muted mode or display something to the user to acquire the gesture.

Comment 16 by, Apr 24 2018

The problem I have with our product ( is that we're just trying to grab the microphone to listen for a short high frequency audio sample. I'm not even playing audio and getting penalized for this. If there's another workaround, I'd certainly like to hear it (No pun intended :) 

Comment 17 by, Apr 24 2018

beccahughes: unfortunately this was not communicated in public to the webrtc ecosytem at all. And the recommendations you link do not mention WebRTC.

This change breaks a number of well-known sites, including:
* (uses it in a pre-call haircheck)
* jitsi meet (uses it during the call; see Saul's comment above)
* (uses it during the call; tokbox is one of the largest webrtc platform providers)
* -- google hosted sample application for how to use this; no updates
* (see
* (oddly not in 66 but only 67?!; uses this is in the haircheck and in the call)

Note that we are talking about a use-case where the user has given permission to the microphone. This requires either a click on the permission dialog which should be counted as an interaction or a persistent permission which implies an even greater level of familiarity with the site.
First-time user interaction may include a button (see e.g. the behaviour of when you enter without permission) but if a persistent permission is detected this goes down a different path.

Note that that the video elements used by WebRTC typically do not have controls even which severely limits the users ability to interact with them. Pausing them (as done in 824866) makes no sense as they are realtime.

When you say 
 - High Media Engagement. We have seen a number of WebRTC apps able to successfully achieve a high MEI score.
can you give some examples?

I would not mind making changes. However, this has demonstrably been flying under the radar and not been communicated properly and running into this as a regression when Chrome 66 is rolling out as stable is not a good way to get acceptance for this.
@fippo - In terms of communications we announced this back in September so that sites could get ready for the upcoming changes and provide feedback. We are unable to disclose MEI data for specific sites.

Comment 19 by, Apr 24 2018

This is affecting all of our customers at TokBox. We have an API built on top of using the audioContext to surface an "audioLevelUpdated" event We also display the audio level to users when they are in audio only mode. This is all not working. 

You can see an example at
The audio level does not move in Chrome 66 but it did previously.

I agree with fippo that giving device permission should be enough for the audiocontext to work as it is with Safari. This also caught us by surprise. 

This is also affecting our customers at Twilio. We built an API on top of AudioContext surfacing a `volume` event with `input` and `output` values for a call:

Our examples repo with audio level indicators is found here, and has issues on M66:
> The problem with the Safari approach is that they are simply allowing any AudioContext to make noise if getUserMedia is on. This is quite risky as it means that a website could potentially pipe any audio through that context.

I don't agree that this is a problem. If the page has been granted permission to the microphone and camera, the page has the ability to record the user, as well as piping that stream to pretty much anything, including broadcasting the user to millions of people if you're really nefarious. That the user might get audio playback is quite frankly at that point the least of the user's worries.

What I'm trying to say is that if the page is trusted enough by the user to be allowed to do that, then implicity its MEI score should go through the roof, and subsequently allow playback of audio (but allowing analysis of audio with no audio output should be allowed anyway imo. but we don't have a good system for that)
I talked to Webex today that's also experiencing problems with this, I've asked them to add their input on this bug. For applications like this it's very common that a calendar/email link brings you directly into a meeting without any user action on the web page.
This issue would simply go away if the getUserMedia user interactions and settings were respected in relation to autoplay. When you do a getUserMedia call to access camera or microphone, the user has to approve access to their device. If that interaction was taken into account for the autoplay decision, that would fix this issue.

Comment 27 by, Apr 28 2018

We also have chromebox for meetings that are difficult to always require users to interact with the page for it for audio to work, besides, the mute proposal wont work because the unmute action is done via the speaker phone which probably wont consider it as an interaction with the page.
Can't boxes set an enterprise policy to disable autoplay permission?
It will also be useful to have a synchronous way to tell if a video can be played with sound or not.
In a web conference there may be participants that don't activate the mic. Everything is async anyway and having to deal with artificial limitation complicate stuff. For example, by the time We get the an error that a video can't be played with sound, the stream may be already gone.

Comment 30 Deleted

Comment 31 Deleted


Comment 33 by, May 7 2018

Labels: Hotlist-Enterprise ReleaseBlock-Stable
I'm flagging this bug as a blocker for some of the Google services. The Apps/Hangouts team may need help from Chrome team to find workarounds. [ b/78484818 ]

Comment 34 Deleted

Labels: -ReleaseBlock-Stable
#29: we are working with Apple and Mozilla on a new API to do this.

#33: royans@, autoplay restrictions are known to impact Google properties as much as other websites. We shouldn't block Chrome release based only on this. Happy to discuss what Hangouts can do offline. I'm not sure we should use the public bug tracker for internal products.

Comment 36 Deleted

Comment 37 Deleted

so great to get updates about this issue... from

(I assume most people here are aware of issue 840866 but mentioning it for completeness sake) 
As noted in issue 840866, the changes to autoplay behavior have been partially rolled back in Chrome 66. Details:

> 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: >

From the WebRTC side, we are going to work on landing some of the improvements discussed in this thread, including We will try to communicate the status of this work regularly.

qq: what would be the expected SLA for fixing this P1 issue (logged in April), affecting Google Enterprise customers?
Many thanks,
We are investigating a connection between GetUserMedia and the autoplay policy and will communicate in more detail when the work has progressed.

Note that with this appears to only allow autoplay for audioContext and only if there is an active capture session
We would appreciate if mic-permission increases MEI enough to cancel autoplay policy changes.

We have WebRTC-based SIP-telephony app, that isn't able to play ringtone from background tab since Chrome 70:
- if you are already logged in (e.g. from previous session), you can just open the page and easily avoid doing ANY interaction with the page.
- for new-ish users MEI is too low.

What should we do now?

We will be probably forced to implement some user-action-detecting overlay for the page just to force user to interact with the page, and warn him/her that we cannot substantially notify him/her about incoming calls otherwise (desktop notifications are easy to overlook). That seems like pretty bad UX for the user.

(Sorry for the late input, our team is not large enough to handle everything in timely fashion)
Note that the best way to alert users of events such as incoming calls is to implement a service worker for sending push notification
A push notification is just not good enough.

We use WebRTC on the web to support calling your doctor. Our UX is that you will be taken to a "waiting room" at the time you are supposed to meet the doctor, and when the doctor is ready they will call you. This can take anywhere from 5 seconds to 15 minutes depending on how busy the doctor is. Visiting your doctor is an important thing, and you want to be clearly notified when the doctor is ready. The user expectation has through extensive user testing been that the page MUST play an audible sound, a ringtone, like a phone would. A push notification is simply not enough to grab the user's attention in this case, they might be idly browsing some other page while waiting, as they would in a real doctor's office.

If we put ourselves in the user's shoes, they expect this experience to work like a phone. If someone important called you, but you didn't know exactly when, wouldn't you unmute your phone and expect a clear, loud ringtone to play for an extensive amount of time until you dealt with it? The web used to be able to do this, but now we have no guarantee for that. Instead we have some shitty machine learning heuristic which has no idea about how important this phone call is to me, as a user.

Please, please, please implement a way to grant permission to play audio, which is guaranteed to work, every time. The machine learning algorithm is NOT good enough, and we have a lot of failed calls last week alone due to the ringtone not playing as it should (both Safari and Chrome).
> Note that the best way to alert users of events such as incoming calls is to implement a service worker for sending push notification

"the best way"? So why do all communication apps & devices use ringtones? Ringtones are industry standard for good reasons (see comment#44), and users expect them.
I agree that users ought to be able to explicitly grant audio permissions. I'm building a progressive WebApp that uses a remote control app to control the WebApp. After the user sets up the WebApp, they do not interact with it directly, and the app will update itself by refreshing when needed, meaning ringtones for the app (it's a video conferencing app) would not be heard.

In the current setup my app would absolutely break. It is only by pure luck that our first iteration is a Chrome Hosted App so is not subject to the autoplay restriction.

If we intend web to be the platform of apps, there needs to be a clear and explicit channel for requesting and holding on to permissions. Machine learning-based, indirect approvals will not cut it, I think.
Some extra info:
* Generating a sound from the "Waiting room" scenario will work if the user has invoked a user gesture in that sessions, which can be as simple as the button that connects the call initially
* Autoplay will also be granted while there is a capture session running.
Yeah so ... does not work anymore. I'm going to fix this by adding an additional button which is not really convenient for the user (he has to allow microphone usage basically twice). 
Vote :)
I’ll point out that if you’re desperate to play a sound you can capture the microphone a split second before you play the audio. As long as you’re technically capturing audio you can play sounds.

Sign in to add a comment