Firefox 66 to block automatically playing audible video and audio

Isn’t it annoying when you click on a link or open a new browser tab and audible video or audio starts playing automatically?

We know that unsolicited volume can be a great source of distraction and frustration for users of the web. So we are making changes to how Firefox handles playing media with sound. We want to make sure web developers are aware of this new autoplay blocking feature in Firefox.

Starting with the release of Firefox 66 for desktop and Firefox for Android, Firefox will block audible audio and video by default. We only allow a site to play audio or video aloud via the HTMLMediaElement API once a web page has had user interaction to initiate the audio, such as the user clicking on a “play” button.

Any playback that happens before the user has interacted with a page via a mouse click, printable key press, or touch event, is deemed to be autoplay and will be blocked if it is potentially audible.

Muted autoplay is still allowed. So script can set the “muted” attribute on HTMLMediaElement to true, and autoplay will work.

We expect to roll out audible autoplay blocking enabled by default, in Firefox 66, scheduled for general release on 19 March 2019. In Firefox for Android, this will replace the existing block autoplay implementation with the same behavior we’ll be using in Firefox on desktop.

There are some sites on which users want audible autoplay audio and video to be allowed. When Firefox for Desktop blocks autoplay audio or video, an icon appears in the URL bar. Users can click on the icon to access the site information panel, where they can change the “Autoplay sound” permission for that site from the default setting of “Block” to “Allow”. Firefox will then allow that site to autoplay audibly. This allows users to easily curate their own whitelist of sites that they trust to autoplay audibly.

Firefox expresses a blocked play() call to JavaScript by rejecting the promise returned by HTMLMediaElement.play() with a NotAllowedError. All major browsers which block autoplay express a blocked play via this mechanism. In general, the advice for web authors when calling HTMLMediaElement.play(), is to not assume that calls to play() will always succeed, and to always handle the promise returned by play() being rejected.

If you want to avoid having your audible playback blocked, you should only play media inside a click or keyboard event handler, or on mobile in a touchend event. Another strategy to consider for video is to autoplay muted, and present an “unmute” button to your users. Note that muted autoplay is also currently allowed by default in all major browsers which block autoplay media.

We are also allowing sites to autoplay audibly if the user has previously granted them camera/microphone permission, so that sites which have explicit user permission to run WebRTC should continue to work as they do today.

At this time, we’re also working on blocking autoplay for Web Audio content, but have not yet finalized our implementation. We expect to ship with autoplay Web Audio content blocking enabled by default sometime in 2019. We’ll let you know!

34 comments

Sam

Awesome work, this is much appreciated!

February 4th, 2019 at 10:50
Ravan Asteris

Yaaay!

When I hit a link at it starts playing, usually a loud, unwanted advertisement, I have been clicking “close” on the page. You are doing content providers a service with this – now I might actually stay on their page instead of reflexively closing it.

Bravo!

– R

February 4th, 2019 at 11:12
jasper

thank you! thank you! This is a much needed feature.

February 4th, 2019 at 12:17
bahadir balban

Whatif we want to bring TV-like experience to our users where clicking a video each time becomes an annoyance?

Here is a case where autoplay is the default preferred and intended way: https://getbuzz.io/c/learning-expressjs/stories/Learn-how-to-develop-a-NodeJS-application-4007962439

At least you can add some “allow autoplays from this site” option?

February 4th, 2019 at 14:04
1. Chris Pearce
  
  We understand that there are valid use cases where users would want to autoplay. That’s why there is user interface where users can whitelist sites which they want to be able to autoplay. Part of the challenge of this feature is balancing annoyance mitigation with enabling genuine use cases.
  
  February 6th, 2019 at 13:11
Tony D

Please block ALL auto play audio, video, and GIF’s and use a play button to activate desired elements. Many websites now detect your bandwith and fill all of the pipe with crap A/V.

February 4th, 2019 at 16:32
1. Chris Pearce
  
  Unfortunately, if we blocked inaudible videos as well, sites would work around this using web technologies like canvas or just show a sequence of images in order to approximate playing video in power draining ways.
  
  February 6th, 2019 at 13:09
  1. Geoff Hart
    
    Although your logic is fine, it misses the point made by Tony D and others: Web developers forcing us to tolerate unwanted audio or video is at best deeply uncool, and probably not so ethical too. Focusing on the difficulty of blocking their efforts is valid and worthwhile if you want to tell us that the development will take time, but it’s not a good final response. There will always be an arms race between crapvertisers and browser developers. We get that. The fact that crapvertisers will try to come up with alternatives isn’t relevant. The fact that they clog the bandwidth and (at some future date) may use this channel to deliver malware is the point (did anyone say “Flash”?). Please reconsider, and provide an option for blocking *all* autoplay options.
    
    February 6th, 2019 at 16:05
    1. Chris Pearce
      
      Sorry, it’s been shown that advertisers will find a way to get the effect of playing video if inaudible videos are blocked. If we followed the cat-and-mouse game to its conclusion, we’d end up having to disable all interactive bits of the web, and that seems like too steep a price to pay.
      
      February 12th, 2019 at 15:50
Eloise

How will ‘muted autoplaying videos’ impact screen reader users?

February 5th, 2019 at 03:16
1. Chris Pearce
  
  We’ve run this past our accessibility experts, and it is acceptable to them. So far the user interface for adding sites to your personal whitelist of sites allowed to autoplay isn’t quite accessible yet, but we’re working on improving that.
  
  February 12th, 2019 at 15:52
NoName

Media of any kind should not be allowed to autoplay period.
It makes no difference if it is muted or not, audio only, video with audio, it should not autoplay.

February 5th, 2019 at 08:29
1. Chris Pearce
  
  Unfortunately, if we blocked inaudible videos as well, sites would work around this using web technologies like canvas or just show a sequence of images in order to approximate playing video. These techniques are less power efficient than just playing inaudible video, so allowing inaudible video is the “least worse” option. Note: this is not a hypothetical concern; one of our competitors observed this when they shipped inaudible autoplay video blocking!
  
  February 6th, 2019 at 11:14
Win Logan

I love Firefox but my hatred for videos that start automatically when I open a web page caused me to switch to Chrome several months ago. Chrome is not perfect at blocking videos, it’s just a little better than nothing. Thank you for fixing this problem in Firefox, I will definitely ditch google chrome when you release Firefox 66 this March.

February 5th, 2019 at 15:05
Painful Insight

So… it will block YouTube? I mean, YT does autoplay videos…

February 5th, 2019 at 19:02
1. Chris Pearce
  
  By default, yes. Like any other site, video on YouTube will not autoplay unless the page you’re viewing has had user interaction. Users can add sites they trust to autoplay to their own whitelist by clicking on the “autoplay blocked icon” in the URL bar. This users can configure Firefox to allow YouTube (or any other site) to autoplay.
  
  February 6th, 2019 at 11:10
Andrew Inggs

I guess it’s too late, but please reconsider. I’ve seen artists say this is approach is so upsetting, it makes them want to remove their art from the internet.

There’s got to be a less heavy-handed approach.

February 6th, 2019 at 11:10
1. Chris Pearce
  
  I understand authors’ frustration, but our research indicates that the vast majority of users do not want audible autoplay. All major browsers are blocking autoplay now, so sites will need to adapt, and display a “start” or “unmute” button in order to work reliably across browsers.
  
  February 6th, 2019 at 13:16
  1. Norbert Süle
    
    I don’t. What prevents artsits to prepare their art to start with an user interaction? It just has to be one click, right?
    
    March 3rd, 2019 at 06:43
    1. Chris Pearce
      
      A page needs a single interaction to unblock autoplay media on that page. Artists may need to add a “start” button to their work.
      
      March 6th, 2019 at 13:31
Lucs Lucs

Thanks for making the world a better place!

February 7th, 2019 at 06:44
Dan Hyatt

I understand and am fully behind this implementation *in cases where I did not explicitly or implicitly ask to see a video.* But as a for instance, say a user is on a site and does a search which returns a list of available videos. They click a link that says “play” beside a video. This opens an overlay iframe with the video in it. Pretty standard for a lot of sites that host videos. Unless I’m misunderstanding the implementation, they’ll have to click the play button on the html player to watch the video even though they’ve already made an explicit request to play the video. Which means two clicks for each view. If you’re viewing more than 3 videos, this is going to get pretty annoying pretty fast.

February 7th, 2019 at 08:12
1. Chris Pearce
  
  In your example, the click to open a video would count as interacting with the document, and thus unblock autoplay in that tab. So if the page then went on to open in iframe inside the document, the content in that iframe would be allowed to autoplay, as one of its ancestor documents (its parent) has had user interaction. This also works if the new document is cross origin (a lot of videos in child iframes are cross origin).
  
  However, if your page opens a new window in which to play the video, then that new window would not be considered to have had user interaction, and a new user gesture would be required before autoplay would work inside that window.
  
  February 12th, 2019 at 15:59
Row

Finally!
Have no idea why it’s taken so long as this has been one of my top internet frustrations for quite some years now.
Turning up your volume to watch one video because the sound is quiet and then suddenly having incredibly loud sound blast in your ear through your headphones as soon as you visit another site just makes me really angry and also shows no consideration for people’s auditory health.
This news makes me happy :)
Thanks for working on great features like this!

February 7th, 2019 at 18:17
Paul Polson

I am glad you are going to implement this!

February 8th, 2019 at 06:45
J Redhead

Hmm… I’m still not happy about this coming to firefox in general due to it’s negative effect on games (https://arstechnica.com/gaming/2018/05/chromes-autoplay-video-blocker-is-accidentally-killing-web-based-games/), but I guess the per-site option somewhat alleviates that, so thank you *very much* for including that!

Will it be possible to disable the auto-sound-blocking by default?

February 10th, 2019 at 14:11
1. Chris Pearce
  
  At this time we are planning on shipping audible autoplay blocked by default.
  
  February 10th, 2019 at 17:00
Adam Chace

Not everything on the web is a news site with ads. These paternalistic changes consistently ignore SaaS based multi-media web applications and keep making our jobs harder. If you must continue to “protect” us give our paying customers a way to opt out of these features for our site.

February 12th, 2019 at 10:09
1. Chris Pearce
  
  Users can click on the “media blocked” icon in the URL bar to access UI to whitelist a site to allow it to autoplay. There’s a screenshot of the UI in the blog post above.
  
  February 12th, 2019 at 15:42
Bananana

There should be an opt-in solution to block ALL autoplay while auto blocking autoplay with sound is active by default.

This should give US an opportunity to turn it off when needed and advertisers will not go crazy and workaround on this.

It’s a fair compromise. (Thus I dont understand why Mozilla started to block trackers when they don’t want a cat-mouse-game with advertisers?! But that’s a different story)

February 28th, 2019 at 08:50
1. Chris Pearce
  
  You’ll be happy to hear that due to popular demand, we’re going to add a checkbox in our preferences menu which allows users to disable inaudible autoplay as well. This will be disabled by default.
  
  February 28th, 2019 at 12:17
  1. Bananana
    
    Thank you! This is exactly what I wanted to hear and what I believe is a great compromise as its disabled by default. Hopefully this has a sort of whitelist like the audible one, then it’s just perfect.
    
    Really, thank you for adding this.
    
    February 28th, 2019 at 22:37
Eric

I have a question about the interaction part. Suppose that I’m on a social network website, where there is a feed, with videos, and many other things to click on.
By default the autoplay would be off (thank you for the option for mute videos!), but what happen when I click/interact on the page, for example clicking on “like”, “retweet”, play a single video, and so on? Will all videos from that point forward be able to autostart with the audio while I scroll down the feed?
My expectation would be that those videos would not autoplay, even if I did that kind of interaction. Even if I played a single video I would prefer not all of them would be able to autoplay :(

March 6th, 2019 at 06:30
1. Chris Pearce
  
  Yes, once you interact with the page, the page will be allowed to autoplay at will until you reload or close the page.
  
  If we required that video could only play inside a gesture handler, what could happen is inside your first interaction with the site, the site would create a bunch of hidden videos which were allowed to autoplay when it so desired. So the two behaviors are roughly equivalent, but one is a lot simpler for site authors.
  
  That said, if autoplay video continues to be a nuisance on the web, we may look at ways to do something like only allowing video to play inside a click handler. But anything we did there would have to be carefully thought through.
  
  March 6th, 2019 at 13:30

Comments are closed for this article.

Hacks

By Chris Pearce

About Chris Pearce

34 comments

Firefox 66 to block automatically playing audible video and audio

By Chris Pearce

About Chris Pearce

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.