New issue
Advanced search Search tips

Issue 807017 link

Starred by 8 users

Issue metadata

Status: Fixed
Closed: Feb 2018
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

issue 802821

Sign in to add a comment

WebAudio user-gesture warning for audio context prevents any audio output

Project Member Reported by, Jan 29 2018

Issue description

Using chrome canary, visit  Press the play button.

There is no sound, and the dev console shows the warning

An AudioContext must be created or resumed after the document received a user gesture to enable audio playback.

This is a warning, not an error.  This breaks all kinds of webaudio applications.

But just reload the page, and the warning no longer appears and audio works.

This is really terrible. As a warning, I don't expect things to break.  If this is going to change, there should be an explicit date on when this will be required.  Otherwise, the change will always be some indeterminate date in the future, which is pretty useless for a developer.


Comment 1 by, Jan 29 2018

Labels: -Pri-3 Pri-1
rtoy@, I'm happy to switch the warning to an error but I don't think we can reduce the autoplay restrictions as Chrome is getting a unified policy across platforms and we can't simply offer a workaround as big as Web Audio.

(The fact that it works after a reload is a bug that I will have fixed soon.)

Comment 3 by, Jan 30 2018

Yeah, I knew the gesture requirement was coming, but there was no warning, or deprecation message or anything to inform people.  This change is going to make lots of webaudio developers mad.

I didn't know this was happening now until all the demos pages I run for testing stopped working.
Chrome did an official announcement that was picked up by the press. We actually announced initially that it will happen in Chrome 64 but it's now targeted to Chrome 66. Hopefully that had enough visibility. I tend to think that it probably had more visibility than a deprecation message. Canary and Dev have been running with this for a while now (late 2017).

Comment 5 by, Jan 30 2018

Which is only relevant if you read the press and understand how it affects you.

Like I said, I knew this was coming, but not exactly when, and I forgot about the exact release (if I even knew).  

I suspect many webaudio developers wouldn't know it affected them.
Blocking: 802821
Just flagging this as an issue and a surprise for us too, I was doing some testing in Soundtrap on Canary this morning and noticed that nothing was playing. I haven't done enough investigation to figure out how big of an issue this will be but we'd certainly appreciate any additional lead time before this becomes default behaviour in Chrome.
Is there a possibility of this restriction working the same way as the new media element autoplay policy, using the media engagement index?

Otherwise the media element might be free to play immediately, but routing it through web audio would still be blocked.
MEI should unlock Web Audio. If it doesn't, please file a bug.

I'm not sure if switching it from a warning to an error is a good idea though, because this 'error' is something that would always happen even if the app handles resuming the audio context properly.

We report any runtime errors to an error logging service, and this includes any `console.error` calls.

Currently we create the audio context at a point which might not be from a user interaction. This is intentional because in the case where this is allowed, it allows playback to start immediately.

If playback can't start because the browser refuses, we then call resume() on the audio context (and play() on the media element) from a user interaction.
Status: WontFix (was: Assigned)
We will not switch to an error as rtoy@ doesn't seem to think it's useful. I have another bug opened about adding link to documentation to the console messages so we will fix that there. The documentation will also include Web Audio.
Yikes, this is a huge change. Thanks for flagging this, Raymond. This will silently break the vast majority of Web Audio applications.

How much time do we have before this ships in the default installation of Chrome?

Is there a ticket for the bug where reloading the page removes the need to unlock the context? This currently makes it quite tricky to verify that a fix is in place and working as expected.


It is very unfortunate that you've found the issue this way. Glad we were able to get your attention on this.

> How much time do we have before this ships in the default installation of Chrome?

You can find out the Stable release date on Currently Canary is M66.

Where can we find that "another bug opened"?

Comment 15 by, Feb 2 2018

Wow, didn't see this coming.

What would be the easiest/best way to start up the AudioContext asap then?

EventListeners at document level? E.g. "onmousemove" and "ontouchstart"?

Comment 16 by, Feb 2 2018

Status: Untriaged (was: WontFix)
I think we should change the phrasing of the message at least.  I read it to mean the context must be created in a gesture.  I think that's not required.  You can create the context as usual.  But to hear audio, you need to call resume() in a user gesture.

Is that right mlamouri?

And I'm reopening this so that it's easily searchable. I realize that the requirement is a done deal, but I want to make it easy for people to find this.

Status: Fixed (was: Untriaged)
rtoy@, as I mentioned above, the phrasing with documentation links will be part of  bug 807646 . fbeaufort@ is updating our doc to make it clear what are the requirements for Web Audio there.

Comment 18 by, Feb 2 2018

Seems way late to be adding documentation, after the fact. 

I don't understand why this blocks 802821.  You can still do the documentation even if this bug is open.

In any case, we did a pretty poor job of informing the WebAudio users about this change.  The webaudio team could have and should have done a better job here.

We're really sorry about that.
I'm wondering how this will affect the way that i currently Unit Test Web Audio code: Will the OfflineAudioContext have a similar restriction so that it can only start rendering after a user-gesture? Also, how will this restriction apply to Headless Chrome (i'm hoping there would be no restriction)?

Thank you for the help!
IIRC, OfflineAudioContext aren't concerned. I'm not sure if Headless Chrome will have this by default but if you run it, you should be able to turn it off.
Seems like it is running in ChromeCanaryHeadless currently. Is there a flag to turn this restriction off? 
You can pass "--autoplay-policy=no-user-gesture-required"
Just to clarify, the following *will* work (right?):

 1. Create AudioContext right during page load
 2. Start some audio playback (should be silent at this point)
 3. Call 'audioCtx.resume()' in a 'click' event listener (event is trusted)
 4. Audio started in step 2 will now be audible
I believe so, yes. I don't know Web Audio well enough to confirm if the internal Web Audio timer will be running or not between steps 1 and 3. In other words, I'm not sure if the playback will appear as muted then audible or simply start time will be delayed.

Comment 25 by, Apr 4 2018

couldn't there be a way to notify the user that the page is attempting to play background audio, and a way for the user to permanently enable it on a per-site basis?

Comment 26 by, May 11 2018

Is there a link to any discussion of why this didn't just follow the iOS Safari / Android Chrome method that the first sound played had to be from a user gesture? That seems like it accomplished the exact same thing and has been working for 4-5 years. Why the need for a new method?
I believe that we are following the same pattern that we standardised. Anything that makes you think we aren't?

Comment 28 by, May 12 2018

The pattern for the last 4-5 years has been, on Mobile, play a sound on user gesture to start audio. I have websites 4-5 years old that did this. They'd check if the user's useragent is mobile, if so they'd put up something to click and play a sound in response to that click.

Following that same pattern, the only thing I'd have to do to fix all my sites is stop checking for mobile and just do the same thing on all my websites.

But that is not what you guys did. Instead you added this new requirement to call resume. That was not a requirement on Android Chrome for Mobile before 66, install only playing a sound in a user gesture was a requirement.

So, I'm curious, why you just didn't continue that pattern and instead made an breaking requirement to call resume?

Sign in to add a comment