> As you browse the web, that list changes as Chrome learns and enables autoplay on sites where you play media with sound during most of your visits, and disables it on sites where you don’t. This way, Chrome gives you a personalized, predictable browsing experience.
Predictable in a user application is the same result from the same action every time. UX changing based on opaque logic and heuristics is anything but predictable.
My bet is that they did this to not break Youtube. I mean it makes sense (you don't want video sites to not work) but it's also such a hacky sort of thing
I don't get why they couldn't make this a permission thing like a mic. Ask the website to allow autoplay.
eh, as a user, it's not really predictable to me whether any given click will result in something autoplaying or not, it already feels like a crap shoot.
I think it depends a lot on how stable the learning is. If it converges and becomes harder to unlearn, eventually you'll be working from a stable platform... but it doesn't carry over to another browser unless you use the sign in feature. So you'll get a stable experience within a browser but not between browsers of the same make/model.
Agreed, it should just be a permission like any other. If I'm on a website where I expect to play media I can remember the preference.
They probably don't want to break websites (as autoplay has no permissions model), but breaking the most annoying feature on the web right now is a good thing.
In Chrome I can type Ctrl+L You <TAB> <Search Query> <Enter> to search YouTube. Chrome figured this out on its own by learning that when I type "You" I usually mean "YouTube". Ever since then that behavior has been very predictable for me. Why would Chrome learning what sites I usually play video on be any different?
Reminds me of fuzzy matching systems like Alfred that will try to learn which key combos you use to launch each app instead of trying to offer you predictability.
But "fi<enter>" never launches Firefox anymore because of that one time you accidentally launched Finder instead. And since you keep accidentally launching Finder that way, it never learns that you want Firefox.
So you try "f<enter>" but you accidentally launch Flux. And because you keep forgetting it thinks "f" = Flux, it always launches Flux.
So you have to use "fir<enter>" to launch Firefox. But "fire<enter>" somehow launches Firewatch, a game you forgot you had installed on your laptop.
It's the most obnoxious system ever where each additional keystroke reorders the entire fuzzy result list in the name of "learning." It really is the opposite of predictable.
Cynicism aside, YouTube is a typical example of a good use for autoplay. A user clicking a link to YT almost always wants to watch the video. "Predictable" probably wasn't the right word for them to use, but I think this is a reasonable move by Google.
I think the real rub here is that the developer of the website doesn’t know if Autoplay is going to work or not. From what i read on this the site doesn’t not get access to any information on if Autoplay did work or is going to work. For many business type of applications this is critical as being as low friction as possible is very important. Autoplay for a web conference, for example, makes perfect sense. But the JavaScript developer doesn’t know if this event failed or worked. Plus what if you aren’t in active development on your product that relies on this? You have to go modify functionality that has been perfectly fine for years.
I also don’t like how quick google is to make such unilateral changes and just boom there they are in production on the web. Good luck Keeping your site browser agnostic. The but ticket for this feature even advised that site developers check to see if the browser is chrome first and then do different logic. What a mess.
Can we find this auto-generated list of enabled/disabled sites anywhere? Can it be edited manually? Will Chrome notify why a particular site did/didn't auto-play a video?
I like Inbox's recent behaviour that explains why it deems a particular email important - it would be good if this sort of explanation was more prevalent with publicly-available ML systems.
Also, I wonder where chrome stores the user’s autoplay history? Will it be cleared when wiping history? Cookies? Or is it never wiped, leaving a record of visited sites in its storage?
Preroll (IMA3) integration with an HTML5 video player is a really tricky dance when you’re trying to support mobile/desktop browsers with a resilient and consistent video player experience. Autoplay has been one of the most difficult differences to manage across browsers.
There’s no browser api that tells you if autoplay is supported, and you won’t get meaningful errors when you try to autoplay when you can’t.
Ultimately the right solution is to just-don’t-autoplay-ever, but it’s a hard sell when you see a 20-40% drop in VOD begins when you remove autoplay.
I’m not sure how to even approach Chrome deciding to autoplay “sometimes”. You have to tell the video player to autoplay a video a.m3u8, but swap that out for preroll.m3u8 before you know if any of it is going to work at all. If it fails, you’re gonna see weird errors in IMA3, or at the video player level, none of which really help you decide how to gracefully handle the situation.
So yeah, if you have client-side preroll, just don’t autoplay I guess.
> Ultimately the right solution is to just-don’t-autoplay-ever, but it’s a hard sell when you see a 20-40% drop in VOD begins when you remove autoplay.
Which tells me that with autoplay enabled, 20-40% of people are probably clicking 'stop' just after the video starts playing, so aren't watching your content anyway.
That means a bunch of ifs in our player code. If iPhone then do that, if chrome then do this, if firefox ... what if chrome, try to autoplay, wait three seconds, fail, disable autoplay, wait for user interaction to run preroll. We'll see how will this end up for our VOD numbers.
>s you browse the web, that list changes as Chrome learns and enables autoplay on sites where you play media with sound during most of your visits, and disables it on sites where you don’t.
What about disabling autoplay even without sound? Unwanted autoplay videos burn through battery even while muted.
They're just modernizing the idea of a GIF. The GIF format was used long after it should have been obsolete, because despite its limitations, it had the key advantage of providing simple, silent animations that autoplay.
Now a lot of "GIFs" aren't in GIF format, they're videos with no sound, and that makes a lot of sense because it's 2018 and we've learned some things about compression and video since 1987.
If silent videos didn't autoplay consistently, people would keep using actual GIFs, using way more bandwidth for the same purpose.
> Quoting the blog post, Google’s decision that ”Muted autoplay is always allowed” is the problem. If any other Chrome users wondered why videos now auto-play without sound (even with this option set), at least based on the relatively minimal docs about this flag, this is why.
Which, sadly, does not actually work for me. I've had it disabled since it first appeared and it has barely made a difference. At least for the news site that play unwanted video. The best I've been able to do in Chrome is to block anything that looks like a CDN using Privacy Badger.
Just tried it. Didn't work. First off the only options are "default", "no user gesture required", "user gesture is required for cross-origin iframes", "Document user activation is required". None of which sounds like "disable autoplay"
Set the flag to "Document user activation is required", restarted browser, went to youtube, videos autoplay
In other words: "If you browse in incognito, you will be punished with annoying videos"
It is in the same line with FB's "your experience will be worse if you choose to delete your data"
On a 1366x768 screen, that blog was painful to read. The header and top menu stuff take up about the top 1/4 of the window (and only folds away near the bottom of the page), and the "related articles" takes the bottom 1/4. Clicking the button to hide related helped some.
My autoplay desires are pretty simple. If the site's Youtube, Vimeo, or another site that exists purely for video, I expect videos to autoplay. It'll annoy me anywhere else. I'd be fine with a whitelist. What I like the least about their new implementation is that the behavior of the browser will change on its own. I don't like my software trying to predict me or changing its behavior without an explicit command to do so.
> Chrome does this by learning your preferences. If you don’t have browsing history, Chrome allows autoplay for over 1,000 sites where we see that the highest percentage of visitors play media with sound. As you browse the web, that list changes as Chrome learns and enables autoplay on sites where you play media with sound during most of your visits, and disables it on sites where you don’t.
Not good enough. I can't even disable autoplay using Chrome's configuration. It doesn't work... but it works on FireFox.
accurate summary: If you don’t have browsing history, Chrome allows autoplay for over 1,000 sites where we see that the highest percentage of visitors play media with sound. As you browse the web, that list changes as Chrome learns.
[+] [-] koolba|8 years ago|reply
Predictable in a user application is the same result from the same action every time. UX changing based on opaque logic and heuristics is anything but predictable.
[+] [-] rtpg|8 years ago|reply
My bet is that they did this to not break Youtube. I mean it makes sense (you don't want video sites to not work) but it's also such a hacky sort of thing
I don't get why they couldn't make this a permission thing like a mic. Ask the website to allow autoplay.
[+] [-] jrochkind1|8 years ago|reply
[+] [-] jadedhacker|8 years ago|reply
[+] [-] gcb0|8 years ago|reply
(hope kids still remember clippy)
[+] [-] ebbv|8 years ago|reply
[+] [-] hammock|8 years ago|reply
[+] [-] sanxiyn|8 years ago|reply
In my experience, "learning" and "predictable" do not go together.
[+] [-] zamalek|8 years ago|reply
They probably don't want to break websites (as autoplay has no permissions model), but breaking the most annoying feature on the web right now is a good thing.
[+] [-] Ajedi32|8 years ago|reply
[+] [-] always_good|8 years ago|reply
But "fi<enter>" never launches Firefox anymore because of that one time you accidentally launched Finder instead. And since you keep accidentally launching Finder that way, it never learns that you want Firefox.
So you try "f<enter>" but you accidentally launch Flux. And because you keep forgetting it thinks "f" = Flux, it always launches Flux.
So you have to use "fir<enter>" to launch Firefox. But "fire<enter>" somehow launches Firewatch, a game you forgot you had installed on your laptop.
It's the most obnoxious system ever where each additional keystroke reorders the entire fuzzy result list in the name of "learning." It really is the opposite of predictable.
[+] [-] gwbas1c|8 years ago|reply
I pretty much continue to install Adblock so I can kill the auto-play elements on websites that just should not autoplay.
[+] [-] billysielu|8 years ago|reply
[+] [-] nightcracker|8 years ago|reply
> predictable
What could possibly be more predictable than disabling autoplay altogether?
Google says it enabled autoplay for 'over 1000 sites', but we all know Google only cares about one thing and that is playing more ads on YouTube.
[+] [-] quadrature|8 years ago|reply
[+] [-] Gaelan|8 years ago|reply
[+] [-] mikob|8 years ago|reply
Since voice isn't counted as a "gesture" the user can't say "play" to start a a video.
It's not just autoplay it's any sort of dynamic (js initiated) playing of media.
[+] [-] mounirlamouri|8 years ago|reply
[+] [-] ledjon|8 years ago|reply
I also don’t like how quick google is to make such unilateral changes and just boom there they are in production on the web. Good luck Keeping your site browser agnostic. The but ticket for this feature even advised that site developers check to see if the browser is chrome first and then do different logic. What a mess.
[+] [-] askvictor|8 years ago|reply
I like Inbox's recent behaviour that explains why it deems a particular email important - it would be good if this sort of explanation was more prevalent with publicly-available ML systems.
[+] [-] asddddd|8 years ago|reply
[+] [-] joosters|8 years ago|reply
[+] [-] potench|8 years ago|reply
There’s no browser api that tells you if autoplay is supported, and you won’t get meaningful errors when you try to autoplay when you can’t.
Ultimately the right solution is to just-don’t-autoplay-ever, but it’s a hard sell when you see a 20-40% drop in VOD begins when you remove autoplay.
I’m not sure how to even approach Chrome deciding to autoplay “sometimes”. You have to tell the video player to autoplay a video a.m3u8, but swap that out for preroll.m3u8 before you know if any of it is going to work at all. If it fails, you’re gonna see weird errors in IMA3, or at the video player level, none of which really help you decide how to gracefully handle the situation.
So yeah, if you have client-side preroll, just don’t autoplay I guess.
[+] [-] Jaruzel|8 years ago|reply
Which tells me that with autoplay enabled, 20-40% of people are probably clicking 'stop' just after the video starts playing, so aren't watching your content anyway.
[+] [-] yilugurlu|8 years ago|reply
[+] [-] curt15|8 years ago|reply
What about disabling autoplay even without sound? Unwanted autoplay videos burn through battery even while muted.
[+] [-] rspeer|8 years ago|reply
Now a lot of "GIFs" aren't in GIF format, they're videos with no sound, and that makes a lot of sense because it's 2018 and we've learned some things about compression and video since 1987.
If silent videos didn't autoplay consistently, people would keep using actual GIFs, using way more bandwidth for the same purpose.
[+] [-] firmgently|8 years ago|reply
[+] [-] crystaln|8 years ago|reply
chrome://flags/#autoplay-policy
[+] [-] troydavis|8 years ago|reply
> Alas, this flag only prevents video that has sound from auto-playing. It’s the inadequate option that my earlier comment was referring to.
>
> Here’s more: https://www.chromium.org/audio-video/autoplay
> https://developers.google.com/web/updates/2017/09/autoplay-p...
>
> Quoting the blog post, Google’s decision that ”Muted autoplay is always allowed” is the problem. If any other Chrome users wondered why videos now auto-play without sound (even with this option set), at least based on the relatively minimal docs about this flag, this is why.
[+] [-] drewg123|8 years ago|reply
[+] [-] voxadam|8 years ago|reply
[+] [-] tokyodude|8 years ago|reply
Set the flag to "Document user activation is required", restarted browser, went to youtube, videos autoplay
[+] [-] crystaln|8 years ago|reply
[+] [-] askvictor|8 years ago|reply
[+] [-] dredmorbius|8 years ago|reply
Ditching Chrome is another excellent and recommended option.
[+] [-] frozenlettuce|8 years ago|reply
[+] [-] rocqua|8 years ago|reply
If google want this on-by-default on youtube, I wouldn't mind. As an upside, this would make it obvious they favor their own product.
[+] [-] khedoros1|8 years ago|reply
My autoplay desires are pretty simple. If the site's Youtube, Vimeo, or another site that exists purely for video, I expect videos to autoplay. It'll annoy me anywhere else. I'd be fine with a whitelist. What I like the least about their new implementation is that the behavior of the browser will change on its own. I don't like my software trying to predict me or changing its behavior without an explicit command to do so.
[+] [-] kodablah|8 years ago|reply
I hate this shit just like I hate their ads program. Where're all the net neutrality proponents when the popular browser vendor is the offender?
[+] [-] panic|8 years ago|reply
[+] [-] chaostheory|8 years ago|reply
Not good enough. I can't even disable autoplay using Chrome's configuration. It doesn't work... but it works on FireFox.
[+] [-] Jyaif|8 years ago|reply
[+] [-] flukus|8 years ago|reply
[+] [-] gumby|8 years ago|reply
Unfortunately this does nothing for moving images (moving ads).
[+] [-] tokyodude|8 years ago|reply
[+] [-] gcb0|8 years ago|reply