Chrome updated to temporarily remove the autoplay policy for the Web Audio API | Hacker News Reader

Chrome updated to temporarily remove the autoplay policy for the Web Audio API

bugs.chromium.org

99 pointsbjornstar73 comments

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.

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

This seems to be the right way to go... Chrome's current approach[0] is all heuristic and no user input. I think a quick "Allow" with an optional "Remember Me" would be both easier to implement and less confusing than what they have (also not a huge pain for web developers.)

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

Google's ongoing approach is to remove the human from the loop. And more and more human facing projects seems to follow suit.

"Any sort of animation"? =(

That would make most good UIs unusable. UI animation and audio aren't remotely the same category of interruption.

Maybe they aren't the same category but there is an indirect link (for me) in that they are both often superfluous and have negative effects on my subjective experience (eg audio: annoyance/data usage, animation: annoyance/slowdown).

I enjoy animation, in art and film. I don't want it in my UIs and always turn it off completely when I have the option. I hated it when Photoshop introduced animated zoom, inertia panning etc, but thankfully could turn those off. It's like a surgeons scalpel with a springy handle, it adds a level of abstraction and indirectness that I don't enjoy. I also prefer to use a Bic Orange razor rather than an over-engineered, sprung, 5-bladed one, because I get direct rather than fuzzy feedback.

The animations in MacOS are honestly a large reason why I don't like it and only use it when I have to. One of the arguments that is often used to justify UI animation is that it helps relate one component to another. Ok so if for some reason I'm unable to work out that the icon I just clicked in the dock caused the application it represents to open, maybe seeing the animation would help. Once. Then I know, so why do I need to see it tens of thousands of times after that, forever re-educating me on this complex relationship of interface components. When I click a button, I just want it to do its job. Not do a little dance for me first. I'm trying to get stuff done.

One of the first things I do with any new Android phone or ROM (after enabling Developer Options) is to turn off all interface animations.

Any of us who have worked with designers or worked as designers ourselves (me, both - and I've made the egotistical mistake I am calling others out for, sure) know that far too often, animations are made because some people think they look 'cool'. Then they come up with back-justifications for them.

I may not be representative of the majority but "That would make most good UIs unusable" couldn't be less true for me.

You can disable animations in macOS and iOS too though, and that also sets the prefers-reduced-motion media query to true in Safari. Bootstrap has just added support for that, but it’s simple to add the same to any web app you’re building (typically you’d use a CSS variable for your default animation speed, and set it to 0 inside the media query).

I think most of the animations in MacOS are informative and there aren’t many I can think of that are needlessly lengthy or intrusive.

The bouncing application icon lets you know the know your app’s status as it opens, and it doesn’t delay your access to a program. The window spread shows you exactly where each window will be placed so that you can quickly find the one you want, and so on.

What animations aren’t you a fan of?

Yours isn’t a popular opinion in the UI world but I agree with you fully and there are a handful of interaction designers who question the dogma on animations.

I think animations is one of the places where a smart smartphone company could attack Apple on a UI basis...

Apple is wedded to a rich multimedia UI. It’s so tightly connected to their brand they have no voice.

But someone who came in with a low-media, animationless UI could best Apple on speed, General “UI mess”, and energy consumption. An interesting UI brand could be built around that.

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

I don't think so. Definitely a state transition though.

If on click it went grey then disappeared it miiight be considered animated.

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

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.

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

Sound is already a permission: chrome://settings/content/sound

Video is, oddly enough, not, even though "images" are.

"Any sort of animation" seems kinda tough to implement without completely breaking just about every modern site. Enforcing it would require, at the very least, disabling JavaScript and crippling CSS.

A whitelist assumes you'll always want all media on a domain to autoplay all the time, which is very likely not the case. I have autoplay disabled in Firefox, even animated gifs have to be started manually, which is exactly what I want, it's the only way to completely avoid surprises. I've heard this is not currently possible in Chrome which seems crazy to me.

A Web Permissions API would be sweet, and only a decade behind mobile...

Everything on the Web is a couple of decades behind native development.

Given the failures of Web based OSes, where even ChromeOS had to reach for Android native apps, it shows we will never get there.

Mobile didn't become "native" until the big players dropped their "open web" promise to throw billions at mobile. They could very easily have synthesized the two, but the profit motive and control of OS/Browser specs was too much for them.

The "open web" was ahead of "native" mobile until the point of apostasy.

Still, Mozilla could have long ago pushed a permissions API that put all web app permissions in a single modal. Instead, of course, Mozilla chased mobile (fail) and an endless sort of silly projects nobody asked for (remember web identity?).

The very last thing we need is even more permission popups.

It would be OK if handled with a preference where the user could choose between 'always autoplay', 'never autoplay', 'ask me whether to autoplay each and every time'. Plus the ability to vary that setting on a site-by-site basis.

This isn't really related but can I set Chrome somewhere to send a header to all servers saying "Yes I agree to get cookies" so that sites won't waste 10 seconds of my life making me click OK on an overlay on top of whatever I was trying to read?

(If 1 billion people spend 10 seconds 100 times over the course of a year or two - a reasonable guess for how many sites they might visit over 2 years which use cookies - this is 277,777,778 hours spent on annoying busy work. We might dollarize this to $2.7 billion in wasted user time / annoyance.)

Each website has its own implementation for the cookie notice, so it's unlikely to be possible for Chrome.

I guess a Chrome extension listing all implementations for major websites could work though.

theres a list available in ublock. just activate it in the settings.

I don't use ublock. Anyway I request that Chrome as a first party allow me to select "I agree to all cookies" and then have it sent that as a header or something else. This really is something that only Chrome and Firefox etc can do. Preferably in the same way :)

Or even better, an option to select "I don't consent to non-exempt[1] cookies. Serve me the cookie-less page"

[1] http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm

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

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.

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.

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.

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

> IMO the best solution is to just mute the autoplaying media until the user interacts with the page

This seems like a good compromise but doesn't sound like enough on its own. Sometimes I just open pages and look at the resulting video and it would be puzzling for it to be muted. Or does "interacts with" include merely viewing the tab? Even though it's religion for me, lots of people never or rarely ever "open in new tab". So this design change would eliminate the benefit.

I really think the only way to do it right is to require user action on each individual media element. If not as the default behavior, then any sane browser should provide a way to enable that behavior and have it actually work. Last I heard Chrome has an option that seems like it should work that way but it does not in practice.

If a game has multiple sound effects controlled by javascript logic, then what is the "individual media element"?

Good question. I was only considering typical animation/audio/video content. I'm concerned that Firefox doesn't seem to require any extra steps for games like the ones at https://www.lexaloffle.com/bbs/?tag=microgame . Unless my clicking on the thumbnail is considered activation.

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

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.

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.

You're saying you like the intent of the policy - that's fair enough. I'm saying that the implementation didn't match the intent - Chrome broke WebAudio sites regardless of whether they followed the intended policy. That's not a big win for anyone, it just breaks content to no benefit.

The simplest solution is to not visit sites that don't respect your point of view. Reward sites who align with your interests and views.

You might be right that someday there would be unethical uses of the WebAudio API but AFAICT there are almost none today. Instead there are lots of sites that abuse the video tag playing video when I want none. A bunch of popular news sites do this.

So, maybe this was a huge win in the future but it was a huge lose now. It affected ~0 advertisers and instead affected 1000s of interesting and experimental sites.

You're making a different argument than the GP.

Mobile Safari already has this requirement and it works in a different way.

The problem is that the Chrome team did it in a completely different way that broke everyone's expectations. It also didn't make any sense. Why would you require the dev to unpause the Context themselves? Why not just unpause it automatically once the user has interacted in the right way? And now that Chrome has moved, what if Edge and Firefox create their own 3rd and 4th standards.

I have a library that was broken by this. It was an easy fix, but it was still headscratching that I needed to do anything. Like most libs, I was already complying with the mobile Safari way of doing things.

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

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

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.

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.

People are getting e-irate at so called "net neutrality" but don't care when corps force their opinions and business decisions on users, or even block them entirely from working with their competitors. (See goog blocking YouTube on Amazon devices, Netflix refusing to offer the streams non-blessed browsers, etc).

How about blacklists like safe browsing lists or lists of pages to enable ad blocking on?

Ad blocking should also be enabled on all pages.

The only reason to ever discriminate between pages is when one has actually committed a crime (e.g. the safe browsing lists)

For anything else my own little blog should be the same as Google’s largest sites.

> Ad blocking should also be enabled on all pages.

But it's not enabled on all pages in Chrome unless you install an extension. By default, Chrome enables built-in ad blocking on specific set of sites that they consider intrusive.

> The only reason to ever discriminate between pages is when one has actually committed a crime (e.g. the safe browsing lists)

Careful, I don't think you're gonna get to see the criminal complaint for all on the safe browsing list. Or you you mean committed a crime in Google's eyes?

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) using the Web Audio API.

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

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.

These WebAudio autoplay problems were reported to Google last year:

https://twitter.com/mcclure111/status/993517176798638080

https://bugs.chromium.org/p/chromium/issues/detail?id=765667

Whole platforms are now broken: Unity, Pico-8, shadertoy, howler.js, phazer.js, pixi.js, kiwi.js, melonjs.... And yeah they broke a feature on the main Google.com page. If you click https://www.google.com/search?q=5+second+timer it will normally beep when the timer goes off.

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.

Write your own browser

Firefox has a setting for disabling autoplay, even for gifs

If there are sites you often visit you can see if there exist a userscript for those sites that may have that feature.

You can also block videos completely with an adblocker.

I use https://chrome.google.com/webstore/detail/disable-html5-auto.... It mostly works - a few videos fail to play when I click, and a very few others manage to autoplay.

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.

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

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.

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.

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.

Of course, the top 1000 sites is exactly where I don't want anything to autoplay, because half of these sites have spurious videos instead of the textual content that you'd reasonably expect, just to pump ad engagement metrics.

It'd be nice to have a whitelist/blacklist import/export, so there can be multiple community-sourced efforts to classify sites into reasonable use of autoplay vs. unreasonable. One can dream.

Many ad-blockers do just that. Of course they also go a step further and block ads altogether, so blocking autoplay becomes unnecessary since there is only "true content" left to be autoplayed.

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.

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.

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

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

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.

Developers make the things users use -- there aren't users without developers. Developer interests therefore often overlap with user interest, even if they don't always. Where they're in tension, the particulars of the solution matter.

Users aren't winning if their web audio apps inexplicably stop playing sound in a new version, if Chrome's decision makers decide to muck around with a standard in such a way that devs acting in perfectly good faith find their Web Audio API stuff breaking/working from release to release, and those devs either have to burn time adapting to the hoops du jour particular to each browser or simply give up trying to hit a moving/multiplying target.

As others have pointed out, there are simpler ways to offer users consideration for opt-in audio.

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 But! If you go to 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.

Why not just stop visiting sites that don't align with your views? Reward sites that respect your views and interests...

1. "Users want to view my website but Chrome is getting in the way.."

2. "Users don't seem to want to visit my website. Perhaps I'm doing something wrong..."

Reply on news.ycombinator.com