Sign Up

To Play, or Not to Play #2 – Firefox blocks audible autoplay by default!

Written by:
February 20th, 2019

Restrictive autoplay policies in browsers were definitely one of the most disruptive changes  that took place in 2018. While it was rolled out with the right intentions to help users enjoy their journey through the web, without being “annoyed” by loud, auto-playing audio/video content, it certainly sent website owners and video developers scrambling to make last minute changes to adopt autoplay rules to continue providing a smooth playback experience for their users.

A little “Browser History”

Let’s have a quick look at what happened last year, here’s our original post for more details:

  • Google started to roll out their new autoplay policy in April 2018 with Chrome 66, along with its MEI (Media Engagement Index). MEI collected anonymous user data to derive a score for a website to determine if audible autoplay is allowed or not. To do that, it takes into account if a user is visiting this site frequently, how long a user consumes its content, and some other website traffic factors.
  • In September 2018, Apple followed suit and introduced Autoplay policies in Safari 11.0 along with its “automatic interference engine” that blocked autoplay by default for most websites. That’s all that is known about the behaviour of this engine. However, a user could whitelist websites to allow autoplay and define a general rule for all websites in the “Preferences” section.
  • MS Edge (Edge HTML 18) followed shortly and implemented their own autoplay control behavior. Their policy allowed users to decide for themselves if they wanted to allow autoplay or not by default, globally or per-site.
  • Firefox 59 had already implemented autoplay policy, which could be enabled via a flag but it wasn’t obvious to every user. It only allowed users to disable or enable autoplay globally, not per-site.

Quick Tip: In case you are wondering what data is tracked by Google’s MEI, you can view this data by opening this URL in your Chrome browser: chrome://media-engagement/

Fast Forward to Today

Let’s take a look at the autoplay horizon now.

Mozilla Firefox / Firefox for Android

On February 4th, Mozilla announced their updated autoplay policy for all users, as part of Firefox 66 beta release. The stable version is expected to be released on March 19th. This will block any non muted autoplay content by default for all websites where user interaction was not detected before. The autoplay policy will also become part of Firefox for Android, and therefore replace its existing one. Like other browsers, a user will have the ability to whitelist certain pages.

“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.”

 

(Source: hacks.mozilla.com)

Google Chrome / Chrome for Android

While their autoplay policy implementation for video content didn’t change much, there is still a lot going on when it comes to handling autoplay capabilities for Web Audio APIs. Latest details about that and how the MEI works is explained here.

There’s one more thing – Progressive Web Applications! Those are available on all desktop platforms now and received an exemption. PWAs are allowed to autoplay with sound by default for pages within the scope of the web app manifest.

Safari

At this point there aren’t any other known changes to the autoplay behavior in Safari, nor in the current technology previews of Webkit itself.

What does it mean for web developers?

The good news is that the autoplay policies behave very similarly across browsers now and have two big commonalities that you can rely on as a developer:

  1. Muted autoplay is always allowed
    By adding the `muted` attribute to the video element you will always be able to autoplay your video content.
  2. The play() API call of the HTMLMediaElement returns a Promise which either resolves if autoplay is successful, or rejects in case autoplay isn’t possible, along with an error message explaining why. This is a best-practise approach recommended by every browser vendor so far.
var promise = document.querySelector('video').play();
if (promise !== undefined) {
    promise.then(_ => {
   // Autoplay started!
}).catch(error => {
   // Autoplay was prevented.
   // Show a "Play" button so that user can start playback.
});
}

How does it work with the Bitmovin Player?

This is how the Bitmovin Player does it too. Its play() API call also returns a promise which either rejects or resolves and therefore can be easily used to handle these situations.

player.load(sourceConfig).then((value) => {
    player.play().then((success) => {
        console.log("play() successful!", success)
    }, (error) => {
        console.log("play() failed!", error)
    })
},
() => {
    console.log('Error while loading new content');
});

If you are using the player configuration `autoplay`, you can leverage the `warning` event of the player which is fired in this case as well:

const playerConfig = {
    key: 'YOUR_PLAYER_KEY_HERE',
    playback: {
      autoplay: true,
    },
    events: {
      warning: (warning) => {
        if (warning.code === 1303) {
          console.log(warning.message);
        }
      },
    },
  };

At Bitmovin, our main goal is to not only arm developers with the best tools and video products, but also provide timely information and solutions to disruptive changes in the streaming landscape. By using our player, we take the proactive steps needed to continue to provide a seamless and smooth experience for your users despite of what happens in the background!

Hope this helps you prepare for the upcoming changes in Firefox 66!

Try it out yourself with our 30 day Free Trial!

Try for Free