Some quotes I like below. I assume the resolution will be something along the lines of "thank you for pointing out that .withgoogle.com needs to be added to the whitelist. ;)
> 2. The second issue is that Chrome allows its own products, and a few other select sites, to autoplay audio. JavaScript API changes should be all or nothing — currently this API change (with the secret 1000+ site index and MEI) favours major players like Google, Instagram, Facebook etc. over small independent artists and content creators.
> Here are some of the many Chrome Experiments listed on the official "Experiments with Google" page ( https://experiments.withgoogle.com/ ) that are now broken by this update.
> Note that there is no indication that audio is muted, and no option to enable audio in any way. Also, these experiments *designed for Chrome* all have audio that now works properly in Safari and Firefox on desktop, but not in Chrome.
Wow. Although I’m not seeing much empathy expressed by the Chrome developers posting in the thread, I hope they realize they made a colossal mistake here, which could have been avoided if they’d been more thoughtful about this change and considered the impact.
Got bit by this hard, since it was a rolling update it was tough to reproduce at first, at least they gave you a nice console warning that your context handling was broken /s.
Fix for us was literally just calling audioContext.resume() in the click handler callback while waiting for onload but would have been nice to have a depreciation/warning period
The biggest annoyance I have with this, besides that they whitelist any sites (YouTube), is that it doesn’t follow a standard, and instead is Google pushing something that breaks a lot of standards compliant things. If they built it into the browser in a way like “this thing wants to play audio, allow,” it would be a much better experience and most likely wouldn’t break that much if done properly. In essence they seem to have went with the half baked approach, without considering the consequences of doing so, instead of treating it like a plug-in.
5 comments
[ 3.2 ms ] story [ 19.3 ms ] threadFix for us was literally just calling audioContext.resume() in the click handler callback while waiting for onload but would have been nice to have a depreciation/warning period