Best practices for headset and handset AR

[AdaRoseCannon]

It seems to me the way to go is

• Default to hit-test from viewer space to support selecting from a phone before you touch the screen
• When XRInputSource added then use that to hit-test from the targetRaySpace

This would work really well to listen for selectstart and do hit testing on whatever input source you get, unfortunately transient input sources are indistinguishable from regular input sources and need to use requestHitTestSourceForTransientInput and have slightly different options.

[Manishearth]

Currently the spec mandates that all transient sources have targetRayMode = "screen", but not vice versa (even though that is true in practice). It's worth considering making that always true, but we can also add a transient bool.

My understanding is that the API is intended to be used by registering against all normal input sources and also adding a transient source listener. Perhaps this can be added to the explainer.

/agenda to discuss how authors should be writing this and to see if we need spec or explainer changes to support that

[Manishearth]

Another thing to note is that transient sources will most likely be generic-touchscreen

[AdaRoseCannon]

Here is what I am currently doing, this really does not feel neat.

• What if something comes up as a more generic than "generic-touchscreen"
• What if there are other transient inputs which are not "generic-touchscreen" so go down the wrong path
• What if weird hardware happens that is not a transient input but for some bizarre reason has "generic-touchscreen" as it's most generic profile

[bialpio]

Seems like we need at least the following for it to be usable:

1. A way of asking a session about profile names of possible transient input sources so that the application knows what it needs to pre-subscribe to. For now this would effectively return only ["generic-touchscreen"].
2. Expose whether a specific hit test source is transient or not so that the code snipped above can be made more neat. :)

The 1. is a bit concerning from privacy standpoint, but it may be fine (we need to see whether it'd expose more information about the UA / device than the sites already have).

(...) and to see if we need spec or explainer changes to support that

Spec changes are definitely needed - the algorithms for hit test source creation do not take into account whether the input source is transient or not. I don't really want to have 2 different APIs that allow the site to do the same thing (i.e. I want to forbid creating a regular hit test subscription from a transient input source), but that means that unfortunately we'd need to special-case the algorithm for requestHitTestSource() method to treat some XRSpaces differently.

[AdaRoseCannon]

Discussed during the 17/11/2020 call created this issue as an action:

#97