Reprise: The Gamepad API works in Chrome but not in Firefox?

Firefox Development
#1

Admins: Please move if necessary but I could not determine a better category for this question/issue.

Ref: My original posting located at

Note the current posting is several updates to Firefox and Chrome later and my current version of Firefox is 95.0.2 (64-bit) as of the date of this posting.

Also note that I am doing development of a joystick-based FPV robot using the GoPiGo3 robot produced by Dexter Industries/Modular Robotics
Viz.: https://gopigo.io

. . . by connecting to a web server running directly on the robot itself.

The problem I am experiencing is that when I try to instantiate the gamepad object via an event listener:

      window.addEventListener("gamepadconnected", (event) => {
        gamepad_connected();  // Gamepad is now connected
        send_data(gopigo3_joystick)  // send it to the robot
        get_more_data();  // continue service loop
      });

and

      function  get_gamepad_data() {
        js = (navigator.getGamepads && navigator.getGamepads()) || (navigator.webkitGetGamepads && navigator.webkitGetGamepads());

. . . the developer console in Firefox returns  js is undefined.

Neither Chrome, (on this same Windows laptop) nor Chromium (on my robot), have this problem and the joystick project works.  (Not particularly well just yet, as there is still work to be done.  :wink:  But, it DOES work on those two browsers.)

I suspect, though cannot prove, that the reason for this is that the web site for this project is being served directly off the robot itself (using Python, flask, and werkzug) and is not a secure site. (I access it by entering the robot’s IP address on my local network.)

Additionally, these robots are used for educational purposes in schools, and to make things easier they start up as their own “access point” that you connect to, open the robots page, (on localhost), and then access the robot’s features.

I realize that all this is because various malware writers want to make our lives difficult - and folks like the people at Mozilla are working hard to prevent this.

Questions:

  1. Is it possible to disable this somehow - at least for development purposes - so that I can verify that it is the absence of a secure site that is causing the problem?

  2. Is there something I can do, server side, (like a special header or something), that will tell the browser that it’s OK to access a gamepad on my local network, or via the robot’s access point?

  3. I also suspect that, eventually, there will need to be some kind of self-signed certificate for the robot.  To add to the complexity of the issue, these robots - especially if they are used in class as access-points - get renamed so that individual robots in a class can be distinguished from each other.

    • Do you have any ideas or suggestions on how to set up this kind of self-signed certificate?

Thanks in advance for any help or advice you can provide.

#2

Yes, the Gamepad API in Firefox is only available in secure contexts, so you’d need to have HTTPS. This is according to specification.

See also the related issue for the spec here:

1 Like
#3

Bern there, done that, have a number of posts on that topic.

Is there any chance that Mozilla will back away from this ridiculous requirement?

My thesis is this:

  1. The people who want to track you, (the Google’s, Meta’s, and such like), have deep pockets and the costs involved with bypassing restrictions like these are trivial to them.
  2. They already have secure sites since the cost of a certificate is less than dog-spit as far as they are concerned.
  3. Since they already have a certificate, they can do whatever they want.

However:

Hobbiests, retirees, (like myself), and many schools don’t necessarily have the cash for a multitude of secure certificates.[1]

Also, if you have ten or twenty robots in a classroom, the school would have to figure out how to get ten or twenty real, root-tracable certificates, one for each robot. As soon as the robot’s name or IP address changes, (for the next class), all the certificates are invalid.

At the very least there should be an “about:settings” setting to disable it.

The correct way to handle this is to realize that a joystick/gamepad is simply another HID device and not burden them with unreasonable restrictions.

====================

  1. Please note the following:

Many schools don’t have the money, time,or resources for someone who is skilled enough with IT tasks to even begin to understand the technicalities of buying and installing secure certificates in a robotics setting as this isn’t always a “plug-and-play” type of setting.

Over on the Dexter Industries forums we often see situations where someone is given a dozen robot kits the week before school starts and told to “get busy!”

We’ve seen postings from completely overwhelmed physical education instructors with no experience whatsoever, wondering where to start first.

You are then going to expect these people to navigate a site like VeriSign, Commodo, or wherever to get a bunch of certificates? And are you naive enough to expect that the totally paranoid school system of the 21st Century is going to allow a bunch of robots to piggyback off of the school district’s domain name - and use it to buy secure certificates?!! Any IT professional in his right mind would have heart-attacks just thinking about it!