There need to be more strict settings for autoplay, not only for video and audio, but for huge GIF files too. I'd put them under "energy saving" settings, as reduced network activity would benefit for server too, not to mention all CPU cycles saved for not decoding all media on client side. Autoplay activation triggers should be reviewed as well, as some sites will happily start autoplaying all media after scrolling down using main scrollbar. That's probably only me, but I still consider scrollbar a part of browsers chrome, not part of website. So interacting with it should not give any hints to website, at least where media autoplay is concerned.
The worst thing is those websites that have some type of 2160p type of video autoplay as a background image, making it unbrowsable on cheaper hardware devices.
But this is more a rant for modern webdev practices I'm not sure much can be done to circumvent it from a browser perspective.
I wish gif’s adhered to prefers-reduced-motion and preferably only played on interaction. I use Toggle Animated Gifs [0], but it’s a global on/off switch, requires a reload, and doesn’t show a hint that something could be animated.
Ublock origin has this feature where it blocks large media files automatically (you have to click to load them). I use it for a long time and never had problems because of it.
I don't need any strict settings for autoplay. I don't need autoplay.
Maybe there could be like a 2Mb cap on each page load that you'd manually had to extend the quota on. Most sites that need more are accidental visits anyway. That should work even if the site is user hostile.
This is a further issue for those using e-ink devices (tablets, e-book readers, monitors), where rapid animation at higher quality settings is exceedingly disruptive --- stuttering, screen-flashing, and the like. (It is possible to display animations, if desired, at reasonable refresh rates using lower-quality display settings, e-ink offers a trade-off between text quality (resolution, ghosting) and refresh rates. But as if there needed to be additional arguments to put a hard stop on highly-distracting design elements, this really stands out.)
I've also found it ... interesting ... to note that a single Web page often has the memory footprint of an entire book (a few MB for just plain text, though that can balloon upwards with complex typesetting and graphics), and that even a browser optimised for e-ink (Einkbro) has roughly 10x the power consumption of the stock ebook reader (Neoreader) on my Onyx BOOX tablet (labeled as an e-book reader, but in fact an e-ink based Android tablet).
I can read books for days on a single battery charge. I can browse the Web for ... a few hours.
I still find it distasteful that Chrome's autoplay policy was "we allowlist a 'fair' list of popular websites that happens to include all of our big domains", when the UX for that isn't meaningfully better than the way it works in Firefox. I can't imagine it actually had much of a positive impact on Google's metrics either, so it felt like a huge waste of effort + additional complexity for nothing.
I wonder if the Firefox team ever considered taking the same approach to make Youtube "just work". Clicking allow the first time and never thinking about it again is pretty easy.
Firefox's default "allow autoplay after interaction" policy doesn't help much in the case of SPAs. Go to a site like ESPN and autoplay will be blocked on the first "page" you visit, but navigating to any subsequent "pages" ends up enabling autoplay since link clicks are intercepted and Javascripted away.
What I really want browsers to adopt is an SPA breaking policy, where click handlers for <a> elements are ignored for non-whitelisted sites.
None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation.
In terms of autoplay, a trick we have to play for iOS is, when you click on something we play a 0.25 second silent MP3 through the audio element. Once that's done, it's "active" and we can use it to play audio.
It's a radio "boombox" type application, so this feature is expected by our users to keep audio playing when they navigate to different features within the player.
It helps if you're the kind of person who only ever opens links in new tabs. Firefox is way better for me than Chrome when I do that. Eg if I'm browsing Youtube's front page and I middle-click three videos in a row, I don't want all of them to start playing at the same time.
I really enjoy this as a feature. There are many times that I don't need a video full frame, but don't want to see the rest of the website page either (I'm looking at you YouTube). I can just pop the video out, and even shrink its size, and then go back to whatever else I need to be looking at.
Sadly, there are so many videos out there that do not need to be videos, yet that's how they are presented for sometimes rational reasons on the "creator's" part.
I don't know if it's still the case, but a while back Firefox would allow muted looping videos to auto play, basically like an animated gif. However, if the video had an audio track (even muted) it would keep the computer from sleeping.
Some of adafruits documentation pages had exactly this combination, so leaving a single page of documentation open would keep my computer from automatically sleeping.
It would be useful if Firefox recorded which configs the user changed. Imagine if you could view a chronological, tabular list of all configs that you changed. Name, default value, changed value, date.
Firefox has all of this except the date. `about:config` lists all config values, values in bold do not match their default or do not exist by default, values can be reverted with one click, and there's a checkbox to filter out unmodified items.
Firefox has fine-grained site permissions, which probably cover this. The UI is pretty obscure, though, and not discoverable, which may be why this option isn't considered in the article.
> I've been buying digital music from one of the reasonably good online sources of it (the one that recently got acquired, again, making people nervous about its longer term future).
You'd need to set up containers, associate them with specific websites (not sure if this is possible or I'm confusing FFMACs with Chrome's own container feature), and then of course tweak your Firefox configuration as you prefer it for the site(s) associated with each container/account.
I wish it would all be disabled. On iOS it is absolute hell to load any page due to it jumping around, and then you scroll and some video starts playing. Do you want me to read the page? Or get distracted? Either PIP with a too small x, or inline, making me think it's part of the story, but it's just another story about Mary eating 36 pastries and winning the eating contest.
For the longest time Ars Technica did this too, with the same video over and over. I can't imagine the bandwidth wasted there.
I honestly at this point, don't feel the need to have anything auto play, if I want video, or audio, I'm well on able to click a button myself.
Auto play = auto advertisement in most cases I encounter it. I can't not see why at this day in age we are prioritizing anyone but the user making the choice of when to play something.
> As discussed in Mozilla's wiki page on blocking media autoplay, the default setting for this preference allows autoplay once you've interacted with that tab,
I despise this idea with a burning passion. It means that the instant you scroll down the page, or bring up a menu, or "interact" for some definition of the word, BOOM! some obnoxious video starts playing.
At the time, there was a lot of noise about the fact that autoplay settings were breaking parts of the web, and I do think that was a problem with Chrome's setup that never really got addressed. My article focused only on Chrome's changes.
Firefox's approach was (imo) better -- it didn't have as much of the weird AI-driven "figure out which domains users interact with" nonsense -- but Firefox's approach was still very clearly influenced by Chrome's, and I would argue that Chrome's approach was incorrect.
At the time, there were two concerns, and Chrome's approach was only intended to handle one of them:
1. Autoplay videos use a lot of bandwidth
2. Autoplay videos are disruptive (specifically, they make noise)
Chrome was worried about #2. They argued (and I agree with this) that these are two separate concerns that need to be tackled separately. But Chrome didn't really go all-in on solving problem #2, they kind of had this weird hybrid approach where they were still trying to stop the data from being streamed, but not always, and if you muted the video it would still be streamed, but if you didn't it wouldn't...
So it became the worst of both worlds.
At the time I argued (and I still think this would be a better approach) that given that the goal was entirely about stopping audio, this should have all been handled through automatic tab muting, not through a change to the web APIs.
That's not to say that blocking large amounts of data or stopping the visual aspects of videos isn't important, but the approach Chrome went with (and that Firefox has subsequently inherited) kind of does nothing well. And I think we still see the effects of that today, even in browsers like Firefox that were admittedly a bit more sensible about not adapting some of Chrome's worst ideas.
Interactions were also a sticking point: Chrome interpreted even highlighting text as a signal that autoplay should be allowed -- which is obviously very easily abusable. I generally think that the user-gesture requirement for permissions is not great; it severely limits what users can do on a page while still signaling that they don't want to grant permission for a random action like autoplaying audio.
It's a tricky problem to solve, but I also think it's a problem that's harder to solve because of some of the previous baggage we've inherited from previous efforts to solve it.
I use Safari instead of Chrome when I want twice the autonomy, and it's really strict to websites trying to play media without interaction. It doesn't even start loading YouTube videos until I click the giant play button. You never even see that button in Chrome, and I can't believe how much I now miss that basic sanity check. Chrome will even start playing dozens of tabs simultaneously if I open a collection of tabs from Bookmarks. Really think there should be a setting that enforces the requirement of initial interaction before playback on every site in all browsers.
[+] [-] butz|2 years ago|reply
[+] [-] antegamisou|2 years ago|reply
But this is more a rant for modern webdev practices I'm not sure much can be done to circumvent it from a browser perspective.
[+] [-] Semaphor|2 years ago|reply
[0]: https://github.com/M-Reimer/toggleanigif
[+] [-] maxcoder4|2 years ago|reply
[+] [-] rightbyte|2 years ago|reply
Maybe there could be like a 2Mb cap on each page load that you'd manually had to extend the quota on. Most sites that need more are accidental visits anyway. That should work even if the site is user hostile.
[+] [-] dredmorbius|2 years ago|reply
I've also found it ... interesting ... to note that a single Web page often has the memory footprint of an entire book (a few MB for just plain text, though that can balloon upwards with complex typesetting and graphics), and that even a browser optimised for e-ink (Einkbro) has roughly 10x the power consumption of the stock ebook reader (Neoreader) on my Onyx BOOX tablet (labeled as an e-book reader, but in fact an e-ink based Android tablet).
I can read books for days on a single battery charge. I can browse the Web for ... a few hours.
[+] [-] thejohnconway|2 years ago|reply
Not sure if this is winnable with the all-powerful JavaScript sitting there nearly always available.
[+] [-] musicale|2 years ago|reply
[+] [-] kevingadd|2 years ago|reply
I wonder if the Firefox team ever considered taking the same approach to make Youtube "just work". Clicking allow the first time and never thinking about it again is pretty easy.
[+] [-] caditinpiscinam|2 years ago|reply
What I really want browsers to adopt is an SPA breaking policy, where click handlers for <a> elements are ignored for non-whitelisted sites.
[+] [-] akira2501|2 years ago|reply
None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation.
In terms of autoplay, a trick we have to play for iOS is, when you click on something we play a 0.25 second silent MP3 through the audio element. Once that's done, it's "active" and we can use it to play audio.
It's a radio "boombox" type application, so this feature is expected by our users to keep audio playing when they navigate to different features within the player.
[+] [-] Spivak|2 years ago|reply
[+] [-] PoignardAzur|2 years ago|reply
[+] [-] pier25|2 years ago|reply
[+] [-] Alifatisk|2 years ago|reply
[+] [-] steve_rambo|2 years ago|reply
[+] [-] dylan604|2 years ago|reply
Sadly, there are so many videos out there that do not need to be videos, yet that's how they are presented for sometimes rational reasons on the "creator's" part.
[+] [-] logro|2 years ago|reply
[+] [-] ddejohn|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] Zetobal|2 years ago|reply
[+] [-] nfriedly|2 years ago|reply
Some of adafruits documentation pages had exactly this combination, so leaving a single page of documentation open would keep my computer from automatically sleeping.
[+] [-] foxhop|2 years ago|reply
[+] [-] zagrebian|2 years ago|reply
[+] [-] Falell|2 years ago|reply
[+] [-] throwanem|2 years ago|reply
https://support.mozilla.org/en-US/kb/site-permissions-panel
[+] [-] mholt|2 years ago|reply
Which store is being referred to here?
[+] [-] pxeger1|2 years ago|reply
[+] [-] camel-cdr|2 years ago|reply
[+] [-] 63stack|2 years ago|reply
[+] [-] ano-ther|2 years ago|reply
Those videos are especially annoying when you have a low-bandwidth mobile connection.
[+] [-] lapcat|2 years ago|reply
[+] [-] narag|2 years ago|reply
[+] [-] karmakaze|2 years ago|reply
> Youtube these days does have a reliable 'disable autoplay' setting
Other than not-logged-in/private mode it always works for me.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] dredmorbius|2 years ago|reply
You'd need to set up containers, associate them with specific websites (not sure if this is possible or I'm confusing FFMACs with Chrome's own container feature), and then of course tweak your Firefox configuration as you prefer it for the site(s) associated with each container/account.
[+] [-] WirelessGigabit|2 years ago|reply
For the longest time Ars Technica did this too, with the same video over and over. I can't imagine the bandwidth wasted there.
[+] [-] Meph504|2 years ago|reply
Auto play = auto advertisement in most cases I encounter it. I can't not see why at this day in age we are prioritizing anyone but the user making the choice of when to play something.
[+] [-] musicale|2 years ago|reply
I despise this idea with a burning passion. It means that the instant you scroll down the page, or bring up a menu, or "interact" for some definition of the word, BOOM! some obnoxious video starts playing.
[+] [-] foxhop|2 years ago|reply
[+] [-] danShumway|2 years ago|reply
At the time, there was a lot of noise about the fact that autoplay settings were breaking parts of the web, and I do think that was a problem with Chrome's setup that never really got addressed. My article focused only on Chrome's changes.
Firefox's approach was (imo) better -- it didn't have as much of the weird AI-driven "figure out which domains users interact with" nonsense -- but Firefox's approach was still very clearly influenced by Chrome's, and I would argue that Chrome's approach was incorrect.
At the time, there were two concerns, and Chrome's approach was only intended to handle one of them:
1. Autoplay videos use a lot of bandwidth
2. Autoplay videos are disruptive (specifically, they make noise)
Chrome was worried about #2. They argued (and I agree with this) that these are two separate concerns that need to be tackled separately. But Chrome didn't really go all-in on solving problem #2, they kind of had this weird hybrid approach where they were still trying to stop the data from being streamed, but not always, and if you muted the video it would still be streamed, but if you didn't it wouldn't...
So it became the worst of both worlds.
At the time I argued (and I still think this would be a better approach) that given that the goal was entirely about stopping audio, this should have all been handled through automatic tab muting, not through a change to the web APIs.
That's not to say that blocking large amounts of data or stopping the visual aspects of videos isn't important, but the approach Chrome went with (and that Firefox has subsequently inherited) kind of does nothing well. And I think we still see the effects of that today, even in browsers like Firefox that were admittedly a bit more sensible about not adapting some of Chrome's worst ideas.
Interactions were also a sticking point: Chrome interpreted even highlighting text as a signal that autoplay should be allowed -- which is obviously very easily abusable. I generally think that the user-gesture requirement for permissions is not great; it severely limits what users can do on a page while still signaling that they don't want to grant permission for a random action like autoplaying audio.
It's a tricky problem to solve, but I also think it's a problem that's harder to solve because of some of the previous baggage we've inherited from previous efforts to solve it.
[+] [-] Unfrozen0688|2 years ago|reply
I block all then manual whitelist for domains like Youtube.
Edge, Brave, Chrome seems to work sometimes, or worse, only lets me block audio and not video.
[+] [-] EasyMark|2 years ago|reply
[+] [-] some1else|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] Edidiongben9|2 years ago|reply
[deleted]