
Chrome updated to temporarily remove the autoplay policy for the Web Audio API - bjornstar
https://bugs.chromium.org/p/chromium/issues/detail?id=840866#c103
======
donatj
I think sites should simply have to ask for audio permissions like they
already do for camera, location or microphone.

The browser trying to figure out if I intended to play audio is way too error
prone versus me just asking.

I work on an audiobook player as a developer have been fighting this junk on
iOS for years, it’s nothing but trouble. If I could just secure a permission
to play audio worry free it’d make my life so much easier. Right now we need
to ensure that all our audio is triggered by a click event, and if it gets too
many steps away from the click event itself, everything breaks. It’s literally
defined and limited how we can abstract our code.

~~~
MrMember
More granular permissions would be great. I would love to have a whitelist for
audio, video, any sort of animation, etc.

~~~
Buge
When I click the upvote button in Hacker News, and the upvote button
disappears, would that be considered an animation?

~~~
chatmasta
No because there is nothing like -WebKit-transition on it.

~~~
pilif
Then people would go back to doing their animations with JS at the cost of
more CPU usage, worse frame rate and worse battery life.

Finding out whether JS is currently animating an element is about as hard as
solving the halting problem.

~~~
nitrogen
JS timers and element modifications could be rate limited. Far far far cry
from the halting problem.

------
jimrandomh
Currently they're saying:

> 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:
> [https://developers.google.com/web/updates/2017/09/autoplay-p...](https://developers.google.com/web/updates/2017/09/autoplay-
> policy-changes#webaudio)

This is wrong and really needs to be reconsidered. Nearly all of the examples
of broken webpages on that thread are write-and-forget games, which will never
be updated; this plan would break them permanently, just to save a little
engineering effort in Chrome.

The solution is simple: display a permissions request, like there currently is
for camera, location and microphone. That's how it should've worked in the
first place.

~~~
Ajedi32
A permissions request isn't a good solution. Instead of having to deal with
auto-playing video on every other site you visit, you'd now have to deal with
a permissions prompt constantly popping up.

IMO the best solution is to just mute the autoplaying media until the user
interacts with the page. Completely transparent to sites, and doesn't burden
the user with unnecessary pop-ups.

~~~
anonymfus
Permission request is not necessary a pop-up prompt. It can be implemented as
an additional state of the sound playing icon in the tab's title for example,
and I am sure that good designers can invent something better.

~~~
unilynx
They already show an inline notification on the address bar when a page is
trying to open a popup. They could've done the same for audio

------
fenomas
This was a really awful change. Not only did it break lots of existing sites,
it broke lots of sites _that weren 't even trying to autoplay_.

Basically the new policy triggered based on how you set up your AudioContext,
regardless of whether you played any sounds. Most sites doing anything
interesting with WebAudio just set up their context at init time (until now
there was no reason not to), so as a result almost every WebAudio demo out
there got broken. I was looking through back issues of Web Audio Weekly and in
Chrome it was a wasteland - nothing worked, autoplay or not.

I know the Chrome team works hard, but sometimes it's hard to believe that
they feel the responsibility of stewardship they have over the web. Breaking
existing content with no benefit to user experience should be considered a
showstopper bug, not something you just delay until "after developers have
time to update their code".

~~~
xfitm3
I live a quiet life and want my browser to be quiet too. I don’t fully
understand the API changes behind this decision but from what I have read this
is a huge win.

The real problem is the unethical use of APIs to increase advertisement
related KPIs.

~~~
sp332
Not that many people are really advocating for autoplay. They just want a way
to enable audio on specific sites. The Chrome changes take control away from
the user.

------
plasma
It's pretty ridiculous that Chrome has a whitelist. This should be enough of a
red flag something isn't right.

~~~
setquk
Yes this worries me. Especially with the market share. Surely a large web
gatekeeper like Chrome would be in violation of anti trust regulation?

~~~
jrockway
What's your legal theory behind an antitrust violation?

If it were the case, why wouldn't we have already been down this road with SSL
certificates? If I want to open the jrockway CA with a policy of "I will
literally sign any CSR with no verification", I can't, because no major
browser vendor will add me to their certificate whitelists. That's not an
antitrust violation.

~~~
setquk
The legal basis is that google operate the largest video delivery site. If
they fail to whitelist smaller organisations then they are operating anti
competitively.

The CA situation is a different model. To be honest the whole trustworthy CA
thing is a joke as we’ve found out recently. The model is broken. Look at
Symantec.

------
lioeters
Whew, that's a relief - until October when the same policy will be applied in
Chromium 70?

As many are pointing out in the issue thread, I hope they figure out a
solution that doesn't break countless existing sites, apps and experiments
(including their own, such as
[https://musiclab.chromeexperiments.com](https://musiclab.chromeexperiments.com))
using the Web Audio API.

I'm also not happy about the whitelist, and suspicious of the new Media
Engagement Index.

------
dmitriid
Somehow no one comments that Chrome team rolled this out in the first place,
and only then went and started asking for examples of broken sites. Even
though their own websited like ”Chrome Experiments” are broken by it. Even
though it would take QA a total of few hours to come up with dozens of broken
sites.

~~~
cpeterso
These WebAudio autoplay problems were reported to Google last year:

[https://twitter.com/mcclure111/status/993517176798638080](https://twitter.com/mcclure111/status/993517176798638080)

[https://bugs.chromium.org/p/chromium/issues/detail?id=765667](https://bugs.chromium.org/p/chromium/issues/detail?id=765667)

------
tananaev
What is the easiest/best way to completely disable any auto-play for videos
until I click on them? When I want to watch a video I'm happy to click on it
to watch.

~~~
dvh
Write your own browser

~~~
FreeFull
Firefox has a setting for disabling autoplay, even for gifs

------
dannyw
Chrome needs to ditch this whitelisted exception for 'the top 1000 sites'.
This is a barrier to every new video platform that wants to compete with
YouTube or Facebook.

~~~
pietroglyph
It appears to be a little more complex than that; this[0] blog post (from
September 2017, but linked in as the official recommendation) provides some
broader context, and also talks about a "Media Engagement Index" heuristic to
determine whether or not to play audio. This doesn't appear to take something
like Alexa rank into account. The requested behavior is very similar to the
actual (recalled) behavior. Per [0], Chrome allows muted (by JS) videos to
play, and then allows audio to play on first interaction (but must be done by
JS.) This is subtly different from the proposed behavior, which asks for this
unmuting to be automated by the browser.

[0]:
[https://developers.google.com/web/updates/2017/09/autoplay-p...](https://developers.google.com/web/updates/2017/09/autoplay-
policy-changes)

~~~
dannyw
It’s more complex, but only the top 1000 sites by MEI is still a hurdle. In
addition, the non-whitelist path requires at least 20 interactions before it
is considered. That’s ridiculous; it should be 3-5 max.

~~~
sp332
It's not only the top 1,000. It was over 1,000 when it first launched and they
said they will expand the list over time.

~~~
tokyodude
That's really irrelevant. Your youtube competitor may never get in that list
if users don't get autoplay on your site. Sure you can train your browser.
Until you switch machines. Or use a public machine. Or use a different
profile. Or use incognito mode.

They're providing a fast lane for the current popular sites and everyone else
gets a slow lane. It's kind of hard to get out of the slow lane when you're
forced to go slow.

------
tokyodude
I actually agree with the motivations if not the outcome.

Here's a maybe dumb suggestion. Make make a new API. Sites using the old API
will get a blocking dialog. Sites using the new API will get the desired
behavior. That way old content is still accessible.

Maybe `new AudioContext2()` or `new AudioContext({version: 2})` or `new
AudioContext({optIntoNewBehavior: true})` where old behavior pops up a modal
dialog?

Just throwing out ideas.

~~~
mattdesl
I may be misunderstanding your comment, but what exactly is the benefit?
Advertising websites can just switch to the new API to achieve autoplay audio,
meanwhile all old sites will have a poor user experience as they will require
additional browser UI and popups to use.

~~~
tokyodude
The new API doesn't autoplay. The old API did. Changing the old API is what's
breaking everything. So, if the old API blocks the page that page is still
accessible. Click "Ok" and it's unblocked. If the page is using the new API
then it doesn't get blocked but it also doesn't autoplay

------
mattdesl
This is terrible. Chrome responded to a major breaking change by simply...
delaying it? The exact same problems will be faced come October.

------
flukus
Why listen to developers? They (and their bosses) created such a hostile
environment for users in the first place, if they'd done the right thing then
this wouldn't need to be baked into the browser at all.

Listen to users, they need protection from developers.

~~~
sp332
Cross-posting my comment from Ars Technica:

So here's how weird and user-unfriendly this is. If you link straight to a
page, it will be muted. [Autoplaying sound - unless you're in Chrome 66]
[http://dryad.technology/gametitle](http://dryad.technology/gametitle) But! If
you go to [http://dryad.technology](http://dryad.technology) first and then
click "Game Title", it plays sound. If you control-click it to open it in a
new tab, it also plays sound. But if you drag the link "Game Title" to the tab
bar to open a new tab, it doesn't. This honestly doesn't look like a fully-
baked feature.

