For years, autoplaying video and audio on the web has been a constant source of frustration for users. Restrictions on autoplaying content have been in mobile browsers for years, partially due to the processing limitations of early smartphones, and partially to conserve mobile data usage. With the release of Chrome 66 late last month, Google introduced new autoplay restrictions on both mobile and desktop Chrome.
While most users (myself included) celebrated this change, there has been plenty of valid criticism. The new policy has significantly affected game developers, many of whom say their games are now broken on Chrome. One developer wrote in a tweet, "the way which people engage with these pages differs in such a way that an autoplay policy designed for text articles with embedded video may not be appropriate."
.@ChromiumDev Hi. Your page about the new autoplay permissions in Chrome 66 says "Please reach out to ChromiumDev on Twitter to share your thoughts" I have feedback concerning the impact on games but I'm not really sure how to give API feedback via Twitter? So I took screenshots: pic.twitter.com/r41OKcyCt0
— mcc (@mcclure111) May 7, 2018
The critism is mostly focused on Google's 'Media Engagement Index,' which is how Chrome determines if the page is allowed to automatically play media. This is an algorithm that takes several factors into account, including how long media is consumed, if the tab is active, and how large the video element is. As such, it's difficult for developers to test how their pages function for all users.
When this rolled out, several of my projects broke - and debugging the issue was/is *incredibly* painful, because guess what? Having the devtools open appeared to *sometimes* count as a user interaction. I was pretty stumped until i figured out how to reliably trigger the block
— Colonel Panic 💻🔨🌐 ෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴෴ (@coderobe) May 7, 2018
In the above tweet, one developer noted that simply using the Chrome Dev Tools (a panel often used while testing pages) counted as user interaction, thus making it difficult to replicate the block and diagnose its effects. Other developers have chimed in with further criticism.
Pretty much all of my online work is broken because of @googlechrome 's update on playing audio. I am feeling that with this decision @Google has effectively killed https://t.co/LEY8FnusuY && https://t.co/1gptd8RYcm and I'm considering taking them down sometime in the near future
— cabbibo (@Cabbibo) May 5, 2018
A very interesting thing about the policy is how it's carefully tailored in such a way it will not affect *Google's* audiovisual content site—YouTube—but *will* affect my site (https://t.co/z3QZrUzGd6). The Chrome autoplay now constitutes a market barrier to entry for AV content pic.twitter.com/b0dvN4a5uY
— mcc (@mcclure111) May 7, 2018
Chrome’s new autoplay policy is a disaster for games and audio art on the web, since anything that’s no longer in active development just wont play sound now. Nearly every Phaser/Unity/Pico8 game will be silenced. Their dev team invites feedback on the new policy at @ChromiumDev
— Bennett (@bfod) May 7, 2018
Google appears open to reversing the change, or at least adapting it to fix web games. The Chrome team has asked developers to submit sites that broke after the policy change, but the discussion about reversing the change has been made private.
In the meantime, Google recommends using the newer WebAudio API, which is not subject to the same limitations. However, this requires rewriting existing games that use normal HTML5 audio and video.
Google is rolling back some of the autoplay changes introduced in Chrome 66. More information is available here.
Loading ...
Comments