
Tell HN: Legacy WebAudio content will break in Chrome 70 - fenomas
Heads up: Chrome 70 (due in October) will restore a content policy that breaks most&#x2F;all WebAudio content that hasn&#x27;t been fixed to follow the policy.<p><i>Edit:</i> Note that in general, content will break even if it follows the intent of the policy (by only playing sounds in response to user input). This is due to the nature of Chrome&#x27;s implementation of the policy.<p>If you maintain any WebAudio code the fix is below. For any code that hasn&#x27;t been fixed and isn&#x27;t maintained, expect it to stop working soon in Chrome. :(<p>--<p>Background:<p>This is part of the &quot;no autoplaying&quot; policy that rolled out in Chrome 66, and was reverted for WebAudio a few days later because it broke everything (including Chrome&#x27;s own webaudio demos). Chrome 70 apparently restores the same implementation, so any content that broke before will break again, unless patched.<p>Past HN discussion: https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17079724<p>Policy info: https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;updates&#x2F;2017&#x2F;09&#x2F;autoplay-policy-changes#webaudio<p>--<p>Fix and tech details:<p>The easiest fix is to add a redundant `ctx.resume()` call to any user input event handler. Once that fires, the audioContext will work normally.<p>Basically Chrome&#x27;s implementation of the policy doesn&#x27;t look at when an audioContext <i>plays sounds</i>, it only cares when (a) the context is created, and (b) `context.resume()` is called. If either of those happens inside a user event handler, that context can play sounds. But if you create a context at startup and never call `resume` (like most WebAudio demos), the context will be muted regardless of whether it waits for user input.
======
jeroenhd
From the WebAudio spec ([https://webaudio.github.io/web-audio-api/#allowed-to-
start](https://webaudio.github.io/web-audio-api/#allowed-to-start)):

> An AudioContext is said to be allowed to start if the user agent and the
> system allow audio output in the current context. In other words, if the
> AudioContext control thread state is allowed to transition from suspended to
> running.

> Note: For example, a user agent could require that an AudioContext control
> thread state change to running is triggered by user activation (as described
> in [HTML]).

This means the user agent (the browser) is allowed to choose when the
AudioContext can be used. It's up to Chrome to determine when playing audio is
allowed.

I can't think of an example where auto playing audio without user interaction
is a good idea anyway. This was explicitly warned for in the moving standard
since at least late
2016([http://web.archive.org/web/20161031141656/https://webaudio.g...](http://web.archive.org/web/20161031141656/https://webaudio.github.io/web-
audio-api/)).

~~~
fenomas
> I can't think of an example where auto playing audio without user
> interaction is a good idea anyway

The point of this reminder is to alert people that most preexisting content
will break _regardless of whether it waits for user input_.

That is, even content that only plays sounds when a button is pressed will, in
general, break, unless it happens to also call `context.resume` in the same
event handler (which content predating this policy generally had no reason to
do).

I'll add a note to the post to make this clearer...

------
rcfox
While this sounds like a good change in theory, it doesn't really help against
people who really, really want to play their sounds.

The same policy exists for popups. You no longer get websites automatically
popping up windows on load. Instead, they hijack all click events so that they
can create popups in response to user actions.

The policy doesn't solve the problem, it just delays it slightly. Is it any
less surprising to have sound play when you attempt to click a link or
highlight text?

~~~
tinus_hn
I presume you never used the web right before popup blockers became a thing,
it was terrible. Really not the same as the few shady sites that use tricks to
show one popup these days.

------
amluto
I can think of a far better browser policy: no sound until the user explicitly
allows sounds for the page. Just like location services.

Because, damn it, I generally don’t want sound. And I definitely don’t want
sound unless I explicitly ask for it.

~~~
uglycoyote
Yes, I agree completely. Reading the discussions, it seems that the chrome
team had sidestepped doing this as it would involve a "non trivial UI" but I
am scratching my head wondering how a dialog box that says "do you want to
allow websites from the domain xyz.com to play sounds?" constitutes a non
trivial amount of UI work.

------
nfriedly
I believe that this restriction has been in effect on mobile for quite some
time (in fact, I don't think mobile Safari ever had WebAudio without this
limitation.)

So, if your code works on mobile right now, it should also work in Chrome 70.

As a developer, it's kind of a PITA. But as a user, I appreciate the fact that
websites won't be able to just start playing audio without _some_ interaction
from me.

Also, to clarify the fix, the WebAudio context must be either created or
resumed in response to a click/tap/etc. I usually just provide some "Go"
button and then create the context in the click handler.

~~~
asplake
I don’t know if this contradicts your belief about mobile Safari, but it
continues to bug me that browsing to CNN often (always?) stops whatever audio
I already have running. I look forward to the day when all browsers prevent
this kind of unwanted behaviour.

~~~
jernoble
That should have stopped happening in iOS 11.4. If you’ve upgraded to-or-past
that and you’re still seeing that happen, please let me know: email in profile
or @jernoble on Twitter.

~~~
asplake
Noticed it only a week ago, but since upgrading to 12.0 I can no longer
reproduce. Awesome!

------
zorpner
As predicted by this comment (and others) on the bug:
[https://bugs.chromium.org/p/chromium/issues/detail?id=840866...](https://bugs.chromium.org/p/chromium/issues/detail?id=840866#c104)

None of the actual underlying issues have been addressed in the last five
months. I would very much encourage people defending this change to _go and
read_ the many well-informed comments there, from people attempting to explain
how many valuable things will be permanently broken by this change.

~~~
tinus_hn
Who would have known? Unmaintained software eventually breaks! Cue the tiny
violins.

------
michaelmrose
So obviously do whatever is required for content to work and if you don't
enjoy being jerked around put a little badge somewhere "Best viewed in
firefox" with a icon and a link to the download page for the users platform.

------
chaz6
I presume that they do not gift the user with a preference to change this
behaviour (either globally or per-sitei), or allow an extension to override
it?

------
larkeith
Does this follow the relevant standards, which I presume exist? Or is Google
making a breaking change and requiring the web change to accommodate?

~~~
gsnedders
> Does this follow the relevant standards, which I presume exist?

Yes.

For <video> and <audio>, the spec only says the UA "may" (RFC 2119) follow the
autoplay steps, and the play() method only does anything "if the user agent
and the system allow media playback in the current context".

For WebAudio, the spec says, "An AudioContext is said to be allowed to start
if the user agent and the system allow audio output in the current context".

So the UA is always allowed to decide whether or not to start playing media.

~~~
sp332
^ Could someone who downvoted this comment explain why? Is it wrong or what?

------
jimmaswell
This whole thing is atrocious. We had a brief period of HTML5 stuff being cool
and fun, and now Google is doing their best to completely ruin it on Chrome,
which has such an undeservedly big market share that web apps have to work
around all these asinine restrictions and gotchas. They already ruined some of
my one-off pages that play sound because now the user has to click them to
start them. Do notification noises even work in Chrome now?

