Securing Gamepad API

Firefox release dates for Gamepad API updates

As part of Mozilla’s ongoing commitment to improve the privacy and security of the web platform, over the next few months we will be making some changes to how the Gamepad_API works.

Here are the important dates to keep in mind:

25 of August 2020 (Firefox 81 Beta/Developer Edition):
.<a href="">getGamepads()</a> method will only return game pads if called in a “secure context” (e.g., https://).
22 of September 2020 (Firefox 82 Beta/Developer Edition):
Switch to requiring a permission policy for third-party contexts/iframes.

We are collaborating on making these changes with folks from the Chrome team and other browser vendors. We will update this post with links to their announcements as they become available.

Restricting gamepads to secure contexts

Starting with Firefox 81, the Gamepad API will be restricted to what are known as “secure contexts” (bug 1591329). Basically, this means that Gamepad API will only work on sites served as “https://”. But don’t worry, it also works on http://localhost too while you are debugging!

For the next few months, we will show a developer console warning whenever .getGamepads() method is called from an insecure context.

From Firefox 81, we plan to require secure context for .getGamepads() by default. To avoid significant code breakage, calling .getGamepads() will return an empty array. We will display this console warning indefinitely:

Firefox developer console

The developer console nows shows a warning when .getGamepads() method is called from insecure contexts

Permission Policy integration

From Firefox 82, third-party contexts (i.e., <iframe>s that are not same origin) that require access to the Gamepad API will have to be explicitly granted access by the hosting website via a Permissions Policy.

In order for a third-party context to be able to use the Gamepad API, you will need to add an “allow” attribute to your HTML like so:

  <iframe allow="gamepad" src="">

Once this ships, calling .getGamepads() from a disallowed third-party context will throw a JavaScript security error.

You can our track our implementation progress in bug 1640086.


As WebVR and WebXR already require a secure context to work, these changes
shouldn’t affect any sites relying on .getGamepads(). In fact, everything should continue to work as it does today.

Future improvements to privacy and security

When we ship APIs we often find that sites use them in unintended ways – mostly creatively, sometimes maliciously. As new privacy and security capabilities are added to the web platform, we retrofit those solutions to better protect users from malicious sites and third-party trackers.

Adding “secure contexts” and “permission policy” to the Gamepad API is part of this ongoing effort to improve the overall privacy and security of the web. Although we know these changes can be a short-term inconvenience to developers, we believe it’s important to constantly evolve the web to be as secure and privacy-preserving as it can be for all users.

About Marcos Caceres

More articles by Marcos Caceres…


  1. Constantin

    In the screenshot, the displayed URL points to …2020/06/securing…, but that’s a 404. It should be …2020/07/securing…
    Please fix this in the post and more importantly in Firefox ;-)

    July 2nd, 2020 at 08:07

    1. Marcos Caceres

      Thanks Constantin! fixed it in the post and in Firefox.

      July 5th, 2020 at 22:01

  2. Jim Harris

    What about those use-cases where a non-secure environment is a requirement? (Or extremely desirable.)

    In my case, I am working on a Raspberry Pi based robot that will use a joystick plugged into a different computer, remote-controlling the robot via a browser connected to a simple video streaming server on the ‘bot.

    I am doing my primary development on Firefox because that will give me the broadest browser coverage “out-of-the-box”. Win, Mac, ‘nix, you name it, all will work and all will work well

    With this, anyone wanting to implement a simple joystick enabled project will have to make sure that every inexpensive implemention requires an expensive third-party certificate for every robot in a classroom? School districts are having a hard enough time getting the money for the dang robots – now you want them in hock up to their ears with Verisign or Comodo?

    I think that’s a bad idea.

    Perhaps there could be an exception for direct browser-to-server connections, perhaps even requiring them to be on the same network?

    I agree. The Internet is a nasty place, and security is important. But let’s not throw the baby out with the bath water. Ok?

    July 2nd, 2020 at 11:24

    1. Marcos Caceres

      Mozilla started up Let’s Encrypt to solve this problem :) You get a certificates for free and it’s used by 225 million+ websites.

      July 5th, 2020 at 21:53

  3. Anonymous

    Maybe there ought to be an exception for localhost?
    So you can still use gamepad over http when it is localhost.

    July 22nd, 2020 at 05:55

    1. Marcos Caceres

      Ah, great point! The definition of `SecureContext` includes localhost otherwise you are right, it would make things difficult for developers. I’ll confirm that and update the post.

      July 22nd, 2020 at 06:44

Comments are closed for this article.