Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New autoplay policy in Chrome

blog.google

Post reply on HN
Print view View original

71–80 of 178 posts

Re: New autoplay policy in Chrome

#71

Post by rubatuga »

always_good wrote: post #54
sanxiyn wrote: post #18

> Chrome does this by learning your preferences... This way, Chrome gives you a personalized, predictable browsing experience. In my experience, "learning" and "predictable" do not go together.

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 " 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 " but you accidentally launch Flux. A…

Unfortunately, macOS does the exact same thing. I'm typing "ph" to "pho", and suddently it matches "photo booth" instead of "photoshop". Absolutely unpredictable...

Re: New autoplay policy in Chrome

#72

Post by tokyodude »

geofft wrote: post #14
panic wrote: post #12

Bret Victor's response: https://twitter.com/worrydream/status/993167096992288771

I genuinely do not understand the artist in the replies who says this has destroyed their work. Can't the website require you to click/tap once to start its thing, without negative impact? I feel like I must be missing something. (There's a mention about not updating code for existing work, which might be it?)

I don't have as many webaudio sites as cabbibo but I can imagine that like me he wanted to get new work done today rather than re-visit 20-50 old projects and spend a 1-10 days updating them all to run.

On the other hand I'm happy that ads can't easily play sounds. I do wish youtube had to play by the same rules.

Re: New autoplay policy in Chrome

#73

Post by tokyodude »

Uehreka wrote: post #55
geofft wrote: post #14

Earlier quoted context omitted.

I genuinely do not understand the artist in the replies who says this has destroyed their work. Can't the website require you to click/tap once to start its thing, without negative impact? I feel like I must be missing something. (There's a mention about not updating code for existing work, which might be it?)

For context,here’s how I had to work around this to get autoplaying audio to work on iOS Safari for an educational VR experience I was building: I start by asking a user whether they want to view the experience in “Stereo Mode” or “Normal Mode”. Whatever they click on, I use that click event to start playing a 500ms long mp3 of silence. When that clip finishes, I use its ‘ended’ event to start it up again. Meanwhile…

I'm frustrated too but it's not really that hard. iOS (and Android) have had restrictions for years. My audio library just attaches an event listener to window for touchstart and mousedown and plays one silent sound via the webaudio API. One started there's no need to do it again.

Of course revisiting 10-50 old projects to make them work again is very frustrating

Re: New autoplay policy in Chrome

#74

Post by tokyodude »

spankalee wrote: post #52
mr_toad wrote: post #43

Earlier quoted context omitted.

Do we really have to pander to people who can’t find a play button? How do these people function at crosswalks or in elevators?

Well, crosswalks shouldn't have buttons. Pedestrians shouldn't have the burden of pressing the button in time to cross on the current signal.

Some signals actually do look at the crosswalk buttons. If no one is waiting to cross they keep the lights green in the direction of the most traffic.

Re: New autoplay policy in Chrome

#75

Post by tokyodude »

_neil wrote: post #20
geofft wrote: post #14

Earlier quoted context omitted.

I genuinely do not understand the artist in the replies who says this has destroyed their work. Can't the website require you to click/tap once to start its thing, without negative impact? I feel like I must be missing something. (There's a mention about not updating code for existing work, which might be it?)

The artist in question has hundreds of pieces of work, many of which he may not have easy (if any) access to anymore. It would take a non-trivial amount of work to fix. But I think he’s also expressing doubt about creating art/work on the web in the future because of things like this.

I agree though it would also be likely if he made them native apps they would stop working as well. Lots of native apps on all platforms stop working without updates. The latest for me is Photoshop CS6 which has a 32bit service that MacOS tells me will cease to function soon >:(

Re: New autoplay policy in Chrome

#76

Post by askvictor »

asddddd wrote: post #62
askvictor wrote: post #24

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.

Seems to be this blob: https://github.com/chromium/chromium/blob/b67034891a23389825...

Gah. A blob with no info about it.

Looking a little further, it appears to be a ProtocolBuffer file, but would a bit of documentation hurt?

Re: New autoplay policy in Chrome

#78

Post by flukus »

Jyaif wrote: post #5

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.

Not that this would be surprising, but does that mean chrome is collecting user data?

Re: New autoplay policy in Chrome

#79

Post by sincerely »

qu4z-2 wrote: post #60
Gaelan wrote: post #46

Earlier quoted context omitted.

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.

Youtube is the worst, because not only does it autoplay, but for the first 2s or so it's faffing around with JavaScript so no matter what you do in that time it will subsequently start playing. Like, it'll show up as "playing" and you pause it, then leave the tab, and like a second later the video will start despite your having paused it. (for the record, at least half the time I open a youtube video I don't want it…

i'm not sure if this is something on my end or google's, but i've noticed that in the past few weeks whenever I open a youtube video in a new tab (staying in the current tab), it won't play until i switch to the new one.

Re: New autoplay policy in Chrome

#80

Post by TeMPOraL »

jadedhacker wrote: post #66
koolba wrote: post #51

> 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 p…

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.

> unless you use the sign in feature

Which then becomes yet another reason to use the sign in feature, and yet another reason to stay with the same browser brand.

Post reply on HN