need a supported way of checking for hit-test capability
blairmacintyre opened this issue · comments
Right now, there is no way to check if a session supports hit-testing. Google's model-viewer takes the approach of checking for the existence of a method on XRSession:
export const HAS_WEBXR_DEVICE_API = navigator.xr != null &&
self.XRSession != null && navigator.xr.isSessionSupported != null;
export const HAS_WEBXR_HIT_TEST_API =
HAS_WEBXR_DEVICE_API && self.XRSession!.prototype.requestHitTestSource;
This is a fragile approach. A browser could chose to NOT expose these methods until a session is created and approved by the user.
Instead, each of these extensions should add a feature to the required/option feature sets in WebXR, and using those should be the only supported way of checking for the existence of a feature.
A browser could chose to NOT expose these methods until a session is created and approved by the user.
This is not spec-compliant.
However, requestHitTestSource existing is meaningless, the underlying device may not support the API. Servo does this, we have an implementation of the API (so XRSession.prototype.requestHitTestSource exists), but the hit-test feature is rejected on Hololens.
The permissions API integration is designed for this, you should use navigator.permissions.query() for this. However, I'm not sure if any implementation implements that part of the spec yet.
A browser could chose to NOT expose these methods until a session is created and approved by the user.
This is not spec-compliant.
Ok, fine. 😄 ... my larger point was that it isn't a reasonable way to test for the capability.
I don't see anything in the spec about adding features to test. That was mainly the point of this issue: as part of getting this approved, we should define an attribute that can be tested for.
I don't see anything in the spec about adding features to test.
I'm not sure what you mean by that? permissions.query() is the API for this, we had a ton of discussions in the past landing on choosing this route eventually.
Like, this issue is a dupe of immersive-web/webxr#794 if i'm understanding it correctly.
I see the permissions API, what I can't find is a list of things I can query for (aside from a few basic space names), nor do I see any indication that hit-test (or anchors, or DOM overlay, or ... ) will have features.
Also, the permissions API does not address the situation that provoked this issue in the first place, which is trying to determine if AR placement is possible before user interaction, so that "enter AR" UI can be hidden instead of giving false promises to the user. As best I can tell from this discussion, our current approach is as good as it gets, but I'm happy to change it if someone can describe a better practice.
Back when we were working on isSessionSupported() there were arguments made in favor of asking what options were supported, for this very purpose. They were shot down in part because of worries about fingerprinting, but (of course) if we can infer much of the same information by looking at methods (as is done in ). All we've accomplished is making the obvious UX harder and fragile.
I personally still think the whole API initialization flow is fundamentally broken, and have since it went down the WebVR requestSession path. This is just another example of the problem with this page driven (vs user/UA driven) approach.
I'd advocate for re-opening the discussion of adding feature detection to isSessionSupported()
@blairmacintyre You cannot infer much of the same information by looking at the methods. The existence of the methods is strictly a browser version issue (ignoring config flags), and that fingerprinting bit is already exposed. Again, browsers conditionally disabling methods based on device support is incorrect. Asking for which features are supported is a device issue and that's a fingerprinting bit we do not yet expose.
@Manishearth fair.
@elalish: what I read from all this is that the test you are doing to detect hit testing isn't really going to be useful soon; all AR-capable web browsers will have such a method (since this is pretty basic), so it'll probably be a no-op.
The only reason it fails for us is our lazy loading of the full API; we're going to fix that soon by loading up a skeleton of the methods that are in the spec at the start.
Closing this issue.