Some notes on Firefox’s media autoplay settings in practice as of Firefox 124
utcc.utoronto.ca
utcc.utoronto.ca
You can also use 'once' to have them stop after first playthrough.
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.
Chrome is toying with custom accept header[1] types but they're used by servers to request information from clients, which is completely missing the point in my opinion.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_ne...
Honestly it's getting a bit too noticeable how a full-featured adblocker is converging on just a way to let the user take back control over the user agent.
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.
Just a second of though about the comment made would show so many issues with the idea, that maybe the idea isn't really a good one. At the least it would provide pause that maybe some sort of refinement is required to be taken seriously by anyone else.
As you can't control other people's choices, you can only control your environment. Which often means Firefox+Ublock/NoScript. I use Safari, but only visit a handful of these kinds of sites and never for long, often immediately closing tabs that show popups and annoying animations. And I have a pihole on my network.
These are companies that have allowed so many people to have a website that essentially is a SPA because that's an easy way for them to deploy template based sites. These are much easier to maintain than WordPress sites. Yes, I agree that most of these sites are simply static sites, and I think it would be amazing if these template JS library sites would allow you to render it flat static site once you hit publish or the equivalent. However, they would probably balk at the notion of not protecting their IP with obfuscated code and delivering readable HTML/CSS. I seriously doubt it takes 2MB of JS to operate these sites, and I'm guessing probably 90% of that code isn't used but is just bundled so the same thing is used everywhere.
However, to prove your point, there are many occasions where I've taken as a weekend project to find a template from Wix or similar that I like, and then recreate it in HTML/CSS by hand. It very much is a smaller site. But that's not something anyone here is disputing. The dispute is that you're wanting a fantasy world, and that's not the one we live in.
Otherwise I guess the limit could be in the tcp layer too.
And the limit would not care about breaking sites. So I guess it would only be aimed at technical users on mobile where bytes count. Unless it is easy to "continue" without serverside state breaking.
[0] https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...
I actually think I'll see if it is possible to do this with extensions api.
I don't need it. I don't want it. I try to disable it. But the setting either is ignored or simply doesn't work.
When and why did browsers give up on reliable autoplay blocking?
But at least there should be an easy way to make a website not have access to your speakers unless you opt in. 99% of the times, it's ads anyway, so the default should be to block sound. But that does not solve the bandwidth waste problem.
Fundamentally, the problem is Javascript. It makes it really hard for the user to be in control.
Not sure if this is winnable with the all-powerful JavaScript sitting there nearly always available.
Most browsers included a popup blocker because everyone agreed popups are annoying, now nearly every website has 3 different JS popups.
I don’t get this web developer attitude of just ignoring the user’s preference and working around it. The user should be in control of what the browser is doing, not the web developer. I really want to love JavaScript but it’s power to override user preferences is inexcusable.
Horrible and totally unnecessary UI change, Apple. You could have easily kept the menu item. This is a frequently used action, it shouldn't be buried in Settings!!
[1]: https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...
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.
Other sites permit one to append ".json" for a raw JSON feed.
There are sites already which provide some form of this, notably sites using MediaWiki (which notably powers Wikipedia and Wikisource) offer multiple download options, though I don't think it's quite as flexible as I'd prefer.
Client support would be the other factor, with current Web browsers not being particularly multi-format. Though to be fair, Firefox, Safari, and Chrome all now natively support PDF documents.
I suspect that a render-to-ePub would be a much better alternative to standard HTML for mobile devices. ePub is inherently fluid, and tends to offer a subset of full HTML capabilities. (ePub is of course an archive of HTML, stylesheet, and other elements, though usually it's more strongly textually oriented than the modern Web is.)
For sufficiently large tablets, PDFs are actually a quite good document format.
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.
What I really want browsers to adopt is an SPA breaking policy, where click handlers for <a> elements are ignored for non-whitelisted sites.
For sites where SPA behavior is necessary (like Spotify), opting in could be done with a one-time browser prompt, like how location access and DRM playback are handled.
This seems like a more realistic solution than just avoiding these sites altogether, for the same reason that people use ad blockers instead of just shunning sites with ads.
It's completely unrealistic to break a major browser API.
Either way, my proposal would make sites that eliminated or hid <a> elements stop working by default, which would disincentivize hostile UX practices.
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.
This breaks a lot of navigation features though, right? For example, middle click or control click to open in a new tab, hovering to see where the link will take you, right clicking to save, copy, or share a link, etc.
Why not just have them be anchor elements with hrefs that refer to the URL that you'll be using the history state with? You can still listen to the click events and perform the required history updates and navigation when that occurs, but if the user interacts with that link outside of just clicking it, it'll behave as they expect. Depending on how your navigation works, this could well be less work overall - this has certainly been my experience with similar projects.
I pretty much only use it for videos yt-dlp + mpv can't open though.
>I managed to somehow disable the button that appears on the video without totally disabling the feature
media.videocontrols.picture-in-picture.enabled -> true
media.videocontrols.picture-in-picture.video-toggle.enabled -> false
media.videocontrols.picture-in-picture.keyboard-controls.enabled -> true
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.
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 keeping your computer awake sounds like a bug though, it’s not intended behavior.
I mean Tools menu -> Page Info -> Permissions
An example: the gong doesn't sounds when a game starts in lichess if you have autoplay disabled for sound. You need to allow that for the site. There are other configurations there like accepting cookies, etc.
Which store is being referred to here?
Those videos are especially annoying when you have a low-bandwidth mobile connection.
Any chance you'll publish it for Linux?
Sorry, no, I don't use Linux.
> Youtube these days does have a reliable 'disable autoplay' setting
Other than not-logged-in/private mode it always works for me.
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.
For the longest time Ars Technica did this too, with the same video over and over. I can't imagine the bandwidth wasted there.
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.
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 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.