Add feature detection for hit test capability

[Piotr Bialecki]

The spec draft does not provide any way to check for hit test support on an XR session.

One possible solution is to extend the definition of feature descriptor from the main spec to allow the apps to request a session that supports hit test. Additionally, we should probably extend XRSession as follows:

dictionary XRHitTestState {};

partial interface XRSession {
  readonly attribute XRHitTestState? hitTestState;
};

The hitTestState will be null if the session does not support hit test API or if it was not requested & is therefore unavailable.

In addition, we could specify that immersive-ar sessions must support hit test API so the request for immersive-ar session would always implicitly contain a hit test feature descriptor. immersive-vr sessions could still optionally support it (see #42).

[Blair MacIntyre]

I think extending the feature descriptor is the right approach. This will need to happen for other features being discusses (geospatial alignment, real-world geometry, camera access, image tracking, etc).

For any of these, they could be provided in required or optional features, and have the same behavior as the current features.

The hitTestState could be a way to go; we could also expose supportedFeatures and have it map to the combined set of requested required and optional features that the session actually supports. That seems preferable in the long run to scattering the session API with an ever-increasing set of flags.

[Piotr Bialecki]

The hitTestState could be a way to go; we could also expose supportedFeatures and have it map to the combined set of requested required and optional features that the session actually supports. That seems preferable in the long run to scattering the session API with an ever-increasing set of flags.

I really like this idea, especially sine we already know that there will be more features that will need it. @klausw - what do you think about this in context of DOM overlay?

[Klaus Weidner]

I'm in favor of a supportedFeatures exposed list. For DOM Overlay, the current draft spec exposes a DOMOverlayType in its state field which distinguishes "screen" vs "floating", so I'd likely be keeping the state field even if supportedFeatures were added.

[Blair MacIntyre]

We should consider if we want "supportedFeatures" to be a truthy set; a feature wouldn't be there if it isn't supported, and "domOverlay" could be have a value of DOMOverlayType if it's there.

[Mounir Lamouri]

Given that we will add a feature descriptor and that the hit test request will reject if the feature isn't available in the case of an optional feature, would it make sense to close this? If hitTestState feels needed in the future, we could easily add it. If we believe supportedFeatures is required, that might be a better discussion on the core spec? WDYT?

[Piotr Bialecki]

Sounds good to me. In addition, this is also how XRSession.requestReferenceSpace() currently behaves, so it doesn't seem that we'd be surprising anyone if we took this approach.

[Mounir Lamouri]

Should this be closed?

[Piotr Bialecki]

Closing, we can discuss ways to expose the information about supported optional features in the main repo (see the mention above).