[HN Gopher] Some notes on Firefox's media autoplay settings in p...
___________________________________________________________________
Some notes on Firefox's media autoplay settings in practice as of
Firefox 124
Author : ingve
Score : 106 points
Date : 2024-03-30 09:14 UTC (13 hours ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| kevingadd wrote:
| 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.
| butz wrote:
| 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.
| Semaphor wrote:
| 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.
|
| [0]: https://github.com/M-Reimer/toggleanigif
| mikae1 wrote:
| image.animation_mode = none im about:config.
| Semaphor wrote:
| Doesn't that completely disable them, only without the
| convenience of a toggle?
| antegamisou wrote:
| 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.
| nine_k wrote:
| Back when Opera was a worthy browser, around 2000, it had
| various bandwidth-saving and CPU-saving controls. In
| particular, it had buttons to prevent loading of large
| images, and IIRC for gif autoplay.
| gevz wrote:
| Vivaldi is worthy successor and have those toggles built-
| in.
| rjzzleep wrote:
| and with such a slow GUI that you couldn't run in on
| those low performance devices even with those toggles
| enabled...
| palmfacehn wrote:
| Send a HEAD request. If the file size is over the threshold,
| don't load it without user consent.
| cqqxo4zV46cp wrote:
| A perfect idea for the people who almost certainly aren't
| using "cheaper hardware devices".
| mariusor wrote:
| I wonder why nobody introduced a "Accept-Max-Size" request
| header?
|
| 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...
| rightbyte wrote:
| 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.
| dylan604 wrote:
| How would that cap work? Would the browser be expected to
| calculate the size of all elements by querying them all
| before loading anything? Would the browser just start
| downloading content counting bits as it goes, and then just
| stop when it reached 2Mb? What if the page was laid out in
| such a way that the JS includes were >2Mb?
|
| 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.
| palmfacehn wrote:
| https://www.rfc-editor.org/rfc/rfc9110.html#name-head
| edflsafoiewq wrote:
| What would happen if you yanked the ethernet cord after 2Mb
| transferred? Same thing. You can't precalculate the size
| since resources are added dynamically (and you can't trust
| HEAD anyway).
| qwery wrote:
| If you want all the javascript, don't count the javascript
| against the quota. If you don't want videos that you're
| never going to play deliberately, set the video quota to
| zero.
| skydhash wrote:
| it's rare for the html file and the associated css is
| bigger than 2MB (much epub books is lighter than that if
| you reduce image size). The culprit are often media (fonts
| included), JS files, and files loaded dynamically. I'd say
| get the HTML and CSS files first, then JS and everything
| else and stops after the 2MB threshold. A lot of currently
| running JS code are unnecessary and I say this as a React
| developer.
| dylan604 wrote:
| so many websites don't actually have full HTML. Instead,
| its just JS that dynamically create elements after fully
| being downloaded. Not acknowledging this just shows how
| much of a not good/realistic/practical idea this is. Pie
| in the sky idealistic concepts are fun sitting in a pub
| having a few pints or while sitting in the circle, but
| they are not productive suggestions in making things
| better.
| skydhash wrote:
| Making things better is forcing website owners to go back
| to server-side rendered applications. I just blocked the
| JS files on my self-hosted instance of Gitea to load, and
| the resulting total size is close to 900kb, with my
| profile picture file at 250kb. It is still usable. With
| JS files, the whole thing is 2.2mb and took two seconds
| to render (0.7 seconds for file transfers). Caching was
| disabled. Most websites shouldn't be SPA. And the actual
| instantaneous navigation argument is often negated by
| slow data loading. Instead of the browser showing a
| loading bar, it's the application doing it.
|
| 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.
| rightbyte wrote:
| I was thinking like, don't make any more request if the
| limit is transgressed. So the limit could be surpassed by
| the last request.
|
| 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.
| qwery wrote:
| UBlock Origin has an option to _block large media elements_
| [0] by default / per-site. You can configure the threshold.
|
| [0] https://github.com/gorhill/uBlock/wiki/Per-site-
| switches#no-...
| rightbyte wrote:
| Hmm... thanks for the tip.
|
| I actually think I'll see if it is possible to do this with
| extensions api.
| musicale wrote:
| > I don't need autoplay.
|
| 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?
| thejohnconway wrote:
| People will start animating with JavaScript through canvas or
| other hacks (like rapidly changing the img src to play frames
| manually).
|
| Not sure if this is winnable with the all-powerful JavaScript
| sitting there nearly always available.
| kevin_thibedeau wrote:
| You win by running NoScript and blacklisting the modern web
| BS.
| RobotToaster wrote:
| Not wrong.
|
| Most browsers included a popup blocker because everyone
| agreed popups are annoying, now nearly every website has 3
| different JS popups.
| dylan604 wrote:
| honestly, I still feel like that is a win for users. pop-
| ups that are modals on a site is not anywhere close to open
| application windows, especially the pop-unders. to me,
| opening another application window on my system is much
| more abhorrent than a site deciding it wants my attention
| somewhere else on its site.
| ryandrake wrote:
| You are right, but it's at least one step in the right
| direction. Browsers are so timid when it comes to giving
| users control, I'll take anything.
|
| 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.
| skydhash wrote:
| I like Safari, but it does not want me to enable JavaScript
| per site.
| ryandrake wrote:
| Safari desktop has recently made toggling JavaScript a
| huge pain in the ass. Before, it was just in the menu:
| Develop -> Disable JavaScript. With the most recent
| Safari, you have to go into Settings, then Security tab,
| then uncheck Enable JavaScript.
|
| 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!!
| maxcoder4 wrote:
| 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.
| thisislife2 wrote:
| Which settings are you specifically referring to in uBlock O?
| I didn't find any 'click-to-load' option for _' Block media
| elements larger than'_ option?
| lesona wrote:
| Check out uBlock Origin's per site switches - subheading
| "No large media elements" [1]
|
| [1]: https://github.com/gorhill/uBlock/wiki/Per-site-
| switches#no-...
| schiffern wrote:
| Then they said "click to load" they meant "click [the
| toggle button in the uBlock Origin panel] to load," not
| "click [the media element] to load."
| forgotmyinfo wrote:
| Not sure what I'm doing, but whatever I'm using with
| uBlock Origin lets me click the media element to load it.
| ZephyrOhm wrote:
| Check out yokoffing's uBO filter lists. Specifically #2
| "click2load" which does exactly what you're seeking. Making
| auto play content click to load.
|
| https://github.com/yokoffing/filterlists?tab=readme-ov-file
| dredmorbius wrote:
| 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.
| skydhash wrote:
| While the web allows for a lot of creative expressions, I
| think we should have companion protocols for alternate
| consumptions methods, something like Gemini for every page.
| An e-ink reader is good for focused reading, but bad for
| interactive or animated content. Just like gwern.net allows
| to add `.page` to every link and get the raw source, you
| could add `.gemini` to wikipedia pages and get a much simpler
| document that you can read on e-ink reader or a cli device
| (should be good for accessibility too).
| csande17 wrote:
| Wikipedia kinda has this already:
|
| https://en.wikipedia.org/wiki/Taylor_Swift?action=render
|
| https://en.wikipedia.org/wiki/Taylor_Swift?action=raw
| musicale wrote:
| You had one job, browser "never auto-play" setting....
| Unfrozen0688 wrote:
| I have found Firefox is the only browser to correctly block
| Autoplay.
|
| 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.
| ano-ther wrote:
| Is there any way to block autoplay on iOS Safari?
|
| Those videos are especially annoying when you have a low-
| bandwidth mobile connection.
| lapcat wrote:
| My own extension StopTheMadness Pro:
| https://apps.apple.com/app/stopthemadness-pro/id6471380298
| orhmeh09 wrote:
| StopTheMadness is amazing. Thank you.
| cassianoleal wrote:
| That extension is incredible, I've been using it for years
| and have recently upgraded to Pro.
|
| Any chance you'll publish it for Linux?
| lapcat wrote:
| > Any chance you'll publish it for Linux?
|
| Sorry, no, I don't use Linux.
| Alifatisk wrote:
| I wish there was a way to fully disable the picture-in-picture
| feature so it never appears on any website again.
| Zetobal wrote:
| It's a giant checkbox in the browsing settings...
| Alifatisk wrote:
| You mean the "Enable picture-in-picture video controls"?
| Zetobal wrote:
| https://mzl.la/3BWkMKs
| echoangle wrote:
| That only affects the controls of the PIP mode, the
| question was how to completely disable PIP mode. A
| sibling comment posted a about:config setting to do this.
| logro wrote:
| I occasionally use that feature. But absolutely every single
| time is by mistake and it has negative effects on my mood.
| Still love Firefox though.
| extraduder_ire wrote:
| I managed to somehow disable the button that appears on the
| video without totally disabling the feature. I find it a lot
| more ergonomic to hit ctrl+shift+] to toggle it.
|
| I pretty much only use it for videos yt-dlp + mpv can't open
| though.
| schiffern wrote:
| >I managed to somehow disable the button that appears on
| the video without totally disabling the feature
|
| Not too hard really. This seems to do it:
|
| 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
| steve_rambo wrote:
| about:config - media.videocontrols.picture-in-picture.enabled -
| false
| Alifatisk wrote:
| Oh thanks, I was always looking in about:preferences but
| found nothing except toggling the video controls for the
| picture-in-picture!
| dylan604 wrote:
| 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.
| narag wrote:
| That was actually useful. Since I stopped logging in to YouTube,
| autoplaying the next video has been a PITA.
| karmakaze wrote:
| I always just toggle autoplay off as soon as I can after
| opening one. It's hardly even a conscious action anymore. Is
| this what was meant in TFA:
|
| > Youtube these days does have a reliable 'disable autoplay'
| setting
|
| Other than not-logged-in/private mode it always works for me.
| narag wrote:
| I was doing that, but it's much better to have it automated.
| Now, I see there are side effects for other sites, but now I
| can fine tune it.
| mholt wrote:
| > 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).
|
| Which store is being referred to here?
| camel-cdr wrote:
| bandcamp probably
| pxeger1 wrote:
| I can't work out why the author carefully avoiding naming it.
| lupusreal wrote:
| Probably because product placement is tacky, and if you're
| not even getting paid for it then why would you do it?
| 63stack wrote:
| Bandcamp
| foxhop wrote:
| did you know that browsers will not autoplay video tags unless
| the video is also muted?
| nfriedly wrote:
| 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.
| foxhop wrote:
| yeah I just tested this, autoplay only works on the video tag
| if muted which seems like it defeats the point.
| afavour wrote:
| It's specifically to replace GIFs. If you don't allow
| autoplay of muted videos people will just use GIFs which are
| way, way more bandwidth intensive.
|
| It keeping your computer awake sounds like a bug though, it's
| not intended behavior.
| padenot wrote:
| Please open a bug at https://bugzilla.mozilla.org/enter_bug
| .cgi?product=Core&comp... if that's the case, and CC
| padenot@mozilla.com, I'll have a look next week.
| nfriedly wrote:
| Here's the bug I filed several years ago:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1684718 - I
| just cc'd you
| zagrebian wrote:
| 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.
| Falell wrote:
| 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.
| narag wrote:
| But does that include the personalized settings for a
| specific site?
|
| 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.
| padenot wrote:
| about:preferences#privacy, scroll down a bit, it's under
| "Permissions". You can also adjust it when on the site,
| using the icon at the left of the URL bar.
| narag wrote:
| Thanks!! :)
| caditinpiscinam wrote:
| 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.
| pier25 wrote:
| Why would you want to break SPAs?
| caditinpiscinam wrote:
| Because most SPAs that I interact with (like ESPN) have no
| business being SPAs (in the sense of hijacking navigation).
| The main motivation behind constructing them that way seems
| to be to circumvent UX safeguards.
| pier25 wrote:
| Wouldn't it make more sense to just stop using apps like
| ESPN instead of breaking a major browser API and big chunk
| of the internet?
| skydhash wrote:
| Would you stop using GitHub as well. They recently move
| to a SPA models and I think search and readme links were
| broken for a few days because of history hijacking.
| caditinpiscinam wrote:
| The key to what I'm envisioning is that it wouldn't break
| a site like ESPN entirely -- it would just break the SPA
| behavior by making links behave like links. The end
| result is that the site would be more usable, not less.
|
| 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.
| zilti wrote:
| Because they deserve to get broken.
| Spivak wrote:
| So SPAs would stop using a elements, style buttons like links,
| and attach handlers to those. I don't think you'll be able to
| accomplish what you want.
| caditinpiscinam wrote:
| They could get rid of links, but that would break search
| engine indexing. This wouldn't be an issue for legitimate
| SPAs like Gmail, but would be disastrous for content-based
| sites. More likely is that they'd keep <a> elements but hide
| them from the user.
|
| Either way, my proposal would make sites that eliminated or
| hid <a> elements stop working by default, which would
| disincentivize hostile UX practices.
| PoignardAzur wrote:
| 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.
| pier25 wrote:
| Not sure if I enabled some Chrome setting or what but when I
| middle click on a Youtube thumbnail the video won't start
| playing until I focus on that tab.
| akira2501 wrote:
| > where click handlers for <a> elements
|
| 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.
| caditinpiscinam wrote:
| That makes sense for an audio-player application -- something
| like Spotify where the user expects playback to continue when
| navigating pages. Even so, I rely on the fact that Spotify
| links are actual links, so that I can open multiple tabs when
| I need to, for example when putting together a complicated
| playlist. Have you considered keeping <a> links as a fallback
| to support this sort of use-case?
| MrJohz wrote:
| > 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.
|
| 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.
| throwanem wrote:
| 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.
|
| https://support.mozilla.org/en-US/kb/site-permissions-panel
| some1else wrote:
| 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.
| dredmorbius wrote:
| Would Firefox's multi-account containers
| (<https://addons.mozilla.org/en-US/firefox/addon/multi-
| account...>) be a way to set multimedia autoplay and other
| configurations on a per-site basis?
|
| 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.
| musicale wrote:
| > 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.
| danShumway wrote:
| I wrote about this issue back in 2018 regarding specifically
| Chrome, and Firefox's settings are derivative of Chrome's:
| https://danshumway.com/blog/chrome-autoplay/
|
| 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.
___________________________________________________________________
(page generated 2024-03-30 23:01 UTC)