3 ms·

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 po

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 8y ago
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 8y ago
  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.
- fenomas 8y ago
  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.
- ksk 8y ago
  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.
- tokyodude 8y ago
  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.
- brian-armstrong 8y ago
  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.

xfitm3 8y ago

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 8y ago
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.
fenomas 8y ago
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.
ksk 8y ago
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.
tokyodude 8y ago
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.
brian-armstrong 8y ago
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.