Skip to content
This repository has been archived by the owner on Jul 22, 2024. It is now read-only.

FxR controller and display names should match the native browser's names. #401

Closed
bluemarvin opened this issue Aug 23, 2018 · 8 comments
Closed
Labels
compatibility Web content compatibility issues UX Issue relates to UX
Milestone

Comments

@bluemarvin
Copy link
Contributor

Hardware

All

Current Behavior

We use the same names on all platforms and do not match any existing platforms.

Possible Solution

We should examine what names are used in each native browser and emulate them. A lot of code is already sniffing for specific platform names and it would be easier to just emulate than try and get existing websites to update their code to look for FxR specific strings.

Context

The FxR controller doesn't work on sketchfab.com because they are looking for specific controller names in their code.

@bluemarvin bluemarvin added the enhancement This issue is a new feature or request label Aug 23, 2018
@cvan
Copy link
Contributor

cvan commented Aug 23, 2018

Good catch. Removing Gamepad#id (the "display name") has come up quite a bit in spec discussions:

I understand that the main reason for the Gamepad#id sniffing is to ensure the buttons and axes are mapped correctly (or re-mapped for particular browser/OS/gamepad configurations, which I myself had to do quite a bit in making HTML5 games).

If there's not already enough information with the current properties, a dictionary of capabilities (per w3c/gamepad#12) could be added so developers don't need to sniff for the name.

@MortimerGoro
Copy link
Contributor

We use the same names on all platforms and do not match any existing platforms.

Actually we have already set different names for each display, so it should report different names on each. But yep, it's good to check we are using names that apps are checking correctly.

For the controllers we set the ones used in AFrame (e.g "Gear VR Remote Controller")

@avrignaud
Copy link

@larsbergstrom and I will figure out webcompat loop.

@cvan
Copy link
Contributor

cvan commented Sep 7, 2018

Whichever we choose, we should make sure they are supported by those defined in this popular library used with three.js: https://github.com/stewdio/THREE.VRController/blob/master/VRController.js. (And obviously make PRs when appropriate.) Oculus Go Controller has been recently added, FYI.

@philip-lamb
Copy link
Contributor

philip-lamb commented Mar 4, 2019

See also #812 and #770.

@philip-lamb philip-lamb added UX Issue relates to UX compatibility Web content compatibility issues P2 Fix in the next development iteration and removed enhancement This issue is a new feature or request labels Mar 4, 2019
@philip-lamb philip-lamb added this to the v1.2 milestone Mar 4, 2019
@cvan
Copy link
Contributor

cvan commented Mar 5, 2019

I've commented on w3c/gamepad#73 (comment). Will update as I do some research on the actual sites possibly impacted by Gamepad#id sniffing.

@cvan
Copy link
Contributor

cvan commented Mar 22, 2019

Is there more to be done here? Oculus Go + VIVE Focus Gamepad#id strings were changed in issue #812 / PR #981.

@philip-lamb philip-lamb modified the milestones: v1.2, v1.1.3 Apr 18, 2019
@philip-lamb
Copy link
Contributor

Closing as resolved.

@philip-lamb philip-lamb removed the P2 Fix in the next development iteration label Apr 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compatibility Web content compatibility issues UX Issue relates to UX
Projects
None yet
Development

No branches or pull requests

6 participants