Tell HN: Legacy WebAudio content will break in Chrome 70

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by larkeith on Tuesday September 25, 2018 @11:03AM (#18066868)

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

[ Parent | on HN ]

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by gsnedders on Tuesday September 25, 2018 @11:13AM (#18066955)

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

[ Parent | on HN ]

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by sp332 on Tuesday September 25, 2018 @01:29PM (#18068442)

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

[ Parent | on HN ]

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by nfriedly on Tuesday September 25, 2018 @11:15AM (#18066978)

This is part of the standard. It basically leaves the choice up to the browser:

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

https://webaudio.github.io/web-audio-api/#AudioContext

Also, I think Apple did it first, (on mobile Safari) and then Google on mobile Chrome, and now on desktop Chrome.

[ Parent | on HN ]

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by fenomas on Tuesday September 25, 2018 @11:18AM (#18067009)

I'm no expert but I believe it follows standards. Quoting the spec:

> Note: For example, a user agent could require that an AudioContext control thread state change to running is triggered by user activation

https://www.w3.org/TR/webaudio/#allowed-to-start

That's essentially what the Chrome policy does - it changes when the AudioContext moves from the "suspended" state to "running".

[ Parent | on HN ]

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by gsnedders on Tuesday September 25, 2018 @11:25AM (#18067107)

That's a non-normative note, the normative statement that allows the behaviour is the paragraph before that.

[ Parent | on HN ]

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by jamesgeck0 on Tuesday September 25, 2018 @11:19AM (#18067021)

It does follow standards, and it does break a lot of old browser games, some of which aren't maintained or can't be easily updated.

[ Parent | on HN ]

Re:Tell HN: Legacy WebAudio content will break in Chrome 70 by kakarot on Tuesday September 25, 2018 @11:17AM (#18067000)

WebAudio is caught in standards limbo. I learned to just stay away from it a while back until it's fully standardized.

What had happened was, Mozilla and Google were working on making their implementations compliant, when Google did the thing they love doing that really makes Chrome no better than IE: implemented their own, incomplete version of WebAudio and sent it out the gate. Mozilla then felt pressure to follow suit.

Then we decided the standards needed to be improved again. So now both browsers have a slow, half-assed, broken implementation of WebAudio that isn't good for too much and that neither of them seem intent on fixing until the standards clear up.

[ Parent | on HN ]