Live data from Hacker News

Google show signs of reconsidering auto mute after developer critique

bugs.chromium.org

11–20 of 56 posts

Re: Google show signs of reconsidering auto mute after developer critique

#13
The Issue report is not very well done.

> Autoplay restrictions on the web have long been inconsistent and served only to impede legitimate use cases.

This is judgmental, and it is not backed up with any data. Has it really "served only" to impede the legitimate uses?

> I've described this in detail in the following blog

Blog promotion.

> What is the expected behavior? Allow audio playback on page load without any user interaction.

Definitively this is not the expected behavior. Chromium team has defined that no audio will be allowed until there is user interaction.

> Abusive content will just blare out audio at the first opportunity.

Yes. This is a red queen race. But doesn't means that it is not worth pursuing.

I think that the point is valid. But the premise of the report, it is not. With the goal of minimizing sound SPAM in the web, Chromium has imposed some drastic measures that require changes in the interfaces of a large unknown amount of Javascript code.

> "These restrictions require special coding to handle them. Instead, the browser could simply allow all playback attempts to succeed, but mute the master audio output. Then the browser can automatically unmute the master audio output the first time the user touches the screen (or whenever else it deems the user is OK with audio)."

The proposed solution is quite good. Let the browser show a button to enable sound like they did with pop-ups. So all the affected companies and individuals don't need to repeat the checks all over the internet, to create a unified experience and to keep legacy games and applications that have no chance of being updated.

But as another post says, there is a lot of corner cases. I can imagine a blind user wanting to have sound without having to read some text.

The company I work for was affected by this change. And there was a lot of problems in production. To fix it, people had to work the weekend. I know that should not be like that, that we need to improve beta browser testing, and such. But sometimes the realities of companies make this kind of behavioral changes difficult.

I hope that Chromium finds a good way of keeping ads muted, while not breaking the Internet.

Re: Google show signs of reconsidering auto mute after developer critique

#14
post #11

I’ll immediately switch to using any browser that blocks auto play by default on all websites without exception.

there's got to be a "Silent Navigation" equivalent to the "Icognito/Private Navigation".

Silent Navigation would block videos, audio, notifications, have an adblocker built-in etc.

that's the dream browser in 2018 IMO.

Re: Google show signs of reconsidering auto mute after developer critique

#16

Earlier quoted context omitted.

That's not my interpretation of their comments at all. #55 "Chrome Product Manager for desktop here. Thank you for posting these examples, they're superful helpful to the team. We didn't intend to break all this awesome existing content that relies on webaudio, and we are investigating paths forward now. More updates will follow on this bug."

that's corporate talk for "we don't care, let's stall and come with even more fucked up solution"

That's overly synical. They broke tons of their own stuff too, so my bet is on this being genuine.

Re: Google show signs of reconsidering auto mute after developer critique

#17

isn't the "Allow website to send Notifications" prompt on 99% of mainstream websites irritating enough?

That’s because the api is badly defined, the javascript call to ask for notification is syncronous so the browser need that annoying blocking popup insteas of something less invasive like the popup notification

Re: Google show signs of reconsidering auto mute after developer critique

#18
post #4

What I don't understand is why they went this convoluted route of trying to assess what's legitimate or not, what's a user interaction or not. Does anyone know why they didn't go the route of other permissions like notifications or location, with a discrete popup that says the page is attempting to play some audio (or video), do you want to allow? If it is legitimate, the user clicks allow once and the site works for…

How often do you see the "want to allow X to display notifications?" or "want to allow X to access your location?"

It's a shitty UX for everyone involved.

It's shitty for the user because they get asked it on SO MANY sites. I see friends/family browsing the web and they will go to a news site, click "no" to notifications, need to click away the fullscreen "want to subscribe to our newsletter" modal, then scroll down to the content. Adding a "want to allow this to display video" is just another step you need before being able to use the site.

And it sucks for site owners because those that legitimately need the ability to display video will have a pretty large percentage of their users react-click "no" on the dialog, meaning the site is broken until that user goes into settings and changes that one manually (and unsurprisingly, just about 0 do that).

Now I don't necessarily agree with the choice they've made here, but I do agree that a permissions dialog isn't the right UX.

Re: Google show signs of reconsidering auto mute after developer critique

#19
post #11

I’ll immediately switch to using any browser that blocks auto play by default on all websites without exception.

Firefox -> about:config -> media.autoplay.enabled -> false

Edit: troydavis points out this Chrome option doesn't actually block autoplay: Chrome -> chrome://flags/#autoplay-policy -> Document user activation is required

Re: Google show signs of reconsidering auto mute after developer critique

#20

isn't the "Allow website to send Notifications" prompt on 99% of mainstream websites irritating enough?

That’s because the api is badly defined, the javascript call to ask for notification is syncronous so the browser need that annoying blocking popup insteas of something less invasive like the popup notification

The javascript call to request notification permissions is async (returning a promise in newer browsers, callback in older ones).

https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...

Post reply on HN