Does requestHitTestSource require an "immersive-ar" session?
thetuvix opened this issue · comments
There is a statement in the non-normative introduction that the Hit Test module "builds on top of WebXR Augmented Reality Module." However, there is no mention otherwise in the Hit Test module of any types, members or enum values defined by the AR module.
In contrast, there is pending future work (#42) to elaborate on UAs intersecting the VR bounded floor plane using this module. Beyond that, a headset having an opaque display is fairly orthogonal to it having sufficient sensor capability to detect planes/meshes. This module should support both VR and AR headsets with those real-world geometry detection capabilities.
The spec should make clear that a UA may implement the hit-test module to intersect planes and meshes for either "immersive-vr" or "immersive-ar" sessions. We should then confirm that this intro sentence still adds clarity.
Good point - I think we can drop the "builds on top of WebXR AR module", especially given the issue you link to. The draft of the spec currently does not describe how the availability of the hit test feature at all - I think we should add one more feature descriptor and then UAs could decide if they support hit test in "immersive-vr" and/or "immersive-ar" sessions.
Sounds good!
For a UA that needs to show an in-session permission dialog, presumably requestHitTestSource is the intended call to hook?
I'd say so - it serves as an entry point to the API so it seems like the right place. I'll take a look and possibly reorder some of the requestHitTestSource algorithm's steps to account for that.
For a UA that needs to show an in-session permission dialog, presumably
requestHitTestSourceis the intended call to hook?
I'm not sure I understand this comment. Are you saying that if a UA wanted to show a permission dialog for letting an app access "hit testing against the world", it would do it in response to this?
Regarding allowing hit tests to work for both VR and AR, let's not make this impossible per spec. If someone wants to allow hit tests in VR, that's up to the UA.
Regarding hit tests prompt, we can easily add this to the spec but I'm not sure we should do that unless there is interest from a UA to do this. The method is async so it's not impossible for someone to add a permission prompt but it seems surprising that a UA would do that especially given that hit tests will be a feature and can be asked as part of the XR permission prompt.
@thetuvix does Edge want to have a permission prompt on calls to requestHitTestSource()? Maybe if it's only an option that you want to have available, we can revisit this later? I do not think it will create any backward compat issues with the API.
Regarding permissions: my assumption has been UAs would have them, or not, but as part of requesting a session. The original point of putting the features in request session was so that a program would know, apriori, if they had certain features. Waiting until requestHitTestSource is called seems too late.