Gamepad support broken on all browsers now?

[qwertychouskie]

https://chromestatus.com/feature/5138714634223616

Looks like Secure Context is also required on Chrome now. It looks like local HTTPS support is needed to bring back Gamepad support to all browsers.

[NoahBres]

rip 😔

[NoahAndrews]

Turning this into an online-hosted Progressive Web App that works offline by adding an appropriate Service Worker is probably also an option. You could host it for free on Netlify (or similar).

[jpdagostino]

why not just supporting using custom ssl certificates?

[rbrott]

Consensus & Standardization
Web Developers: Strongly negative

☹️

why not just supporting using custom ssl certificates?

I haven't looked into it until now. The main annoyance is getting your CA for 192.168.43.1/192.168.49.1 trusted by the system. Maybe we can get by with this approach? I might try it out if I get the chance.

[rbrott]

Oh never mind, I guess we have advanced the target SDK! I guess we moved past 19 after my time in the program.

[jpdagostino]

You have to get the client to trust it. It doesn't matter if the host device does or doesn't as long as the webserver supports it.

[rbrott]

Oh duh, thanks for correcting me

…

On Thu, Feb 23, 2023, 1:07 PM jpdagostino ***@***.***> wrote: You have to get the client to trust it. It doesn't matter if the host device does or doesn't as long as the webserver supports it. — Reply to this email directly, view it on GitHub <#131 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABS6GQSNPHS5NZXEATINEVTWY7GR7ANCNFSM6AAAAAAU5O3BJI> . You are receiving this because you commented.Message ID: ***@***.***>

[nash-pillai]

I added a console log in gamepadMiddleware.ts and I can see the gamepad data. It appears to just not be sent to the robot.

[nash-pillai]

The problem was that our gamepad was not on the supported gamepad list. After adding support for it, it worked fine on localhost and 192.168.43.1.

Turning this into an online-hosted Progressive Web App that works offline by adding an appropriate Service Worker is probably also an option. You could host it for free on Netlify (or similar).

When we tried hosting on a website (https://ftcdash-pwa.vercel.app/dash) to use it as a PWA, we could not connect the WebSocket. Apparently, to make a websocket connection, both sides have to use HTTP or both have to use HTTPS, but to access the gamepad on firefox, you need the website to be on HTTPS (it works fine on chromium over HTTP). So now we are just using FTC-Dash hosted on the robot controller and accessed through Chromium.

https://chromestatus.com/feature/5138714634223616

Looks like Secure Context is also required on Chrome now. It looks like local HTTPS support is needed to bring back Gamepad support to all browsers.

I tried it on Chromium (the open source one) Version 108.0.5359.71 (Official Build) (64-bit) on Linux (NixOS) and was able to access the gamepad without HTTPS

[NoahBres]

Another possible alternative I got working a while ago was wrapping Dash in Tauri (Electron alternative) to make it a "native" app.

Might unlock some cool possibilities.

Worked fine with little hassle. Personally, I've found PWA's + service workers to be a bit of a hassle, at least for LRR and axed it recently.

[j5155]

Any way custom certificates could be supported? https://github.com/FiloSottile/mkcert was happy to generate them for 192.168.43.1 and Firefox on my laptop accepts them, I'm just not sure where to start to get them used by the robot.

[jpdagostino]

Since the IP address is basically always going to be the same, the same cert could be used by all robots.

[j5155]

I also managed to get the Tauri version working like Noah suggested: https://github.com/jdhs-ftc/ftc-dashboard
(currently not set up to connect to a robot, only works with https://github.com/j5155/rr-preview-via-dash/, but that could be changed)