Firefox Autoplay Policy Documentation

Last updated : 2020/04/07 from Gdoc

What is autoplay? and What is blocking autoplay?

There are some things which can produce sound on the web, such as the HTMLMediaElement and AudioContext. Websites have an ability to start them automatically without asking users. For example, websites can start the media element via adding the `autoplay` keyword or calling its “play()” method.

However, that ability has gradually been abused by websites, and more and more annoying autoplay unexpectedly happens that has harmed the user experience of browsing pages on the web.

Therefore, we introduce blocking autoplay on Firefox that prevents pages arbitrarily starting media and we have two different strategies to block autoplay which would result in different Behaviors.

How to enable or disable blocking autoplay on Firefox?

On desktop, you can go to the page “about:preferences#privacy”, find the “Autoplay” and click “Settings…”, then you can see “Default for all websites” by which you can decide to enable blocking autoplay or not.

On desktop/mobile, you can enable/disable blocking autoplay by modifying the value of the pref media.autoplay.default.

Set it to 0 would allow all media to autoplay, to 1 would to block audible media to autoplay and to 5 would block both audible and inaudible media to autoplay.

What strategy does Firefox use for blocking autoplay?

We have three different policies for blocking autoplay, and users can change the policy being used by modifying the pref `media.autoplay.blocking_policy`.

Sticky user gesture activation (default)

[when the pref media.autoplay.blocking_policy=0]

This policy would block autoplay for the page which hasn’t been activated by user gestures, which includes keyboard pressing (printable keys, carriage return key and space key), mouse clicking, touch (includes both touch and pointer event).

Once the page has been activated by user gestures, then we would not block any autoplay anymore. That’s why it’s called `sticky`, because the activation would keep until a user refreshes the page or leaves the page.

Transient user gesture activation

[when the pref media.autoplay.blocking_policy=1]

The reason why we need this policy is because lots of websites would show a media unrelated pop-up or an option which requires users to have an interaction with. For example, GDPR Cookie Law. Users might not want to start autoplay just because they accept the cookie law.

This policy is similar with the first policy, but the difference is the activation is not “sticky”, which is “transient”. The activation would expire after a certain period of time, once the activation expires, we would start blocking autoplay again.

Modify the pref `dom.user_activation.transient.timeout` that defines a constant number (in ms) indicating how long a user activation is available.

Eg. When dom.user_activation.transient.timeout=5000 (ms), a user clicks on the page, and if the site starts playing media within 5000ms, then it would be allowed to play. If it starts media after 5000ms passes, then it would be rejected to start.

Click-to-play

[when the pref media.autoplay.blocking_policy=2]

This policy is the oldest blocking autoplay policy, which would only allow the play invocation that is treated as an user intention. The technical detail for this policy is that the play invocation should be triggered inside an user input event handler.

For example, when a user clicks the element X, then we only allow a website to start the element X from a function that is in the call stack based on the X's “click” event handler.

However, because the spec of the propagation of user input flag, which can determine if the function is triggered by the user or not, wasn't well defined, that causes a compatible problem where we can't play media correctly in some situations. For example, if the play invocation for the element X is triggered inside an async handler, then that invocation would not be treated as a valid user input.

Therefore, this mechanism might cause some websites not be able to play any media, if they requests playing from async handlers.

How do we know if the media is blocked or not?

When the media is being blocked, there would be a small blocking icon showing near the URL bar.

When clicking that blocking icon, it would show the detailed information of this website and we can update the customized autoplay permission for each different website.

Can users customize their own autoplay websites list?

Currently, it can only be done on desktop version Firefox. When you modify the autoplay permission from the control center panel, like Img2. It would automatically add the site to the user's customized autoplay permission list.

You can see the whole list by going to the page “about:preferences#privacy” first, then find the “Autoplay” and click “Settings…”. In that setting page, users can see the list which includes different autoplay permission settings for different websites.

Do developers have a way to know if a site can start autoplay?

Yes, sites can know if the specific media element is allowed to autoplay by using “HTMLMediaElement.allowedToPlay” API. That API hasn’t become a formal specification yet, but we believe other browser agents would also implement this API soon. This feature can be turned on by the pref media.allowed-to-play.enabled, which is only enabled by default on Nightly for now.

Does blocking autoplay affect web audio?

For now, we only block web audio on the Nightly version of Firefox. Changing the pref media.autoplay.block-webaudio to enable/disable this feature. In addition, according to the spec, we would only block web audio if a user is using “sticky user gesture activation” policy.

Does blocking autoplay work differently on Android?

Currently, we haven’t supported customizing the autoplay permission list on Android, but we would like to get the applications which are embedding GeckoView have more controllability for the blocking autoplay. Therefore, when the autoplay is not allowed by the current policy, we would ask the application to see if they want to allow the autoplay or not, which allows the application to be involved in determining the final result of the blocking autoplay. The application would receive the autoplay request from websites through the PermissionDelegate and the autoplay permission request would Where can I report related bugs? be dispatched to the callback function onContentPermissionRequest().

The permission name for those requests would be “PERMISSION_AUTOPLAY_AUDIBLE” or “PERMISSION_AUTOPLAY_INAUDIBLE” that indicates that audible or inaudible autoplay might happen on that site and the application can decide if they should be allowed or rejected.

Applications can use that mechanism to customize their own autoplay setting list, to decide which website should always allow autoplay or deny autoplay. This feature can be controlled by the pref media.geckoview.autoplay.request.

But notice that, the request would only happen before the media hasn’t been allowed to autoplay by our autoplay policy. If the media has been allowed by our autoplay policy, then we would not dispatch any request to the application. For example, if the autoplay media starts after a user has clicked somewhere on the page, then all autoplay would be allowed without asking the application.

Where can I report related bugs?

File a bug on bugzilla

Step1. Go to this bug which is used for tracking all blocking autoplay related issues

Step2. Press “New/Clone” button on the top-right corner

Step3. Press “... that blocks this bug”

Step4. Enter the issue you find and press “Submit Bug” when you finish

Report bug on Matrix

Feel free to join the room #media and report bugs to us directly!