(Re) consider isSessionSupported query for required features.

[nbutko]

I am working on a project that requires local-floor as a supported reference space. This project will have different behavior on devices that support local-floor and devices that don't.

In particular, if local-floor is supported, the page will show a lobby + Enter XR button which calls requestSession. If local-floor is not supported, it will fall back to a different UI treatment which informs the user that camera and device orientation access permissions will be requested.

In order to determine which initial interface and potential user prompt to show, I need to know ahead of time whether local-floor is supported. Currently the only mechanism to do this is to request a session and have it fail with NotSupportedError, but by that time it is too late for my UI. Instead, I believe the only way to achieve this is through user agent testing with a whitelisted set of known local-floor capable devices.

Separately, there is an issue with Chrome on Android not reporting the correct error status when requesting local-floor as a required feature: https://bugs.chromium.org/p/chromium/issues/detail?id=1251434

[Manishearth]

We already have a lot of fingerprinting concerns about isSessionSupported(), I'm a bit wary of enabling it to expose further details about the system. Some of this could be managed with more permissions prompts but I'm not really sure.

[Maksims]

If there are permissions asked by querying a list of supported features, would the same permission allow starting a session without a second prompt?

This would provide a way to either: start session > ask permission, or: check supported list of features > ask permission, then start the session with the already given permission.

This only shifts the permission gate but provides the ability to query the supported list of features.

[AdaRoseCannon]

/agenda requested by Nick from 8th Wall (@nbutko)

[nbutko]

The goal is to prepare the user appropriately for which kind of permissions will be requested before requesting them.

[Manishearth]

There may be an approach here that instead gets implementors to estimate the real hit-tested floor whenever possible; this has been discussed a bit amongst implementors.

[sevaseva]

• What is the current status of this?
• Was a decision made whether to extend isSessionSupported() with reference space?
• Any chance isSessionSupported() may also start accepting requiredFeatures in the future?

I assume the answers are all negative -- because of the privacy/fingerprinting concerns, permissions implications, etc. It would just be nice to hear them.

---

It also would be nice to see this discussed and explained in places like

• WebXR Explainer when it talks about isSessionSupported and requestSession
• MDN isSessionSupported and requestSession

because, indeed, it is natural for a developer to want to determine exactly what XR capabilities are supported before deciding what UI to render AND it also seems natural for functions isSessionSupported() and requestSession() to have identical set of arguments.

[Manishearth]

I don't think there has been any motion on this, and I don't think there was consensus on extending isSessionSupported().

When we were first getting approval for this API, isSessionSupported() was contentious because even with a permissions prompt it is the kind of permissions prompt some websites may spam, leading to permissions fatigue.

Someone would have to do the work of designing this in a way that is acceptable to the W3C privacy WG, that implementors are willing to implement. I don't think there has been any signal from implementors on this, and nobody has started such work yet.

[klausw]

If I remember right, one alternative being discussed was to have the site propose a list of session configurations, and then having the browser provide a user interface for starting sessions based on the subset of that list that it supports. This way the site would not get any feedback about supported options unless the user actually chooses the corresponding session-starting button.

However, I think there wasn't much enthusiasm for this approach since the site wouldn't have control over how these options get presented, and it's also challenging to design the browser UI in a way that's both discoverable and not obnoxious when activated unexpectedly.

Also, in some cases checking for supported options isn't possible in a non-invasive way, for example if it requires launching SteamVR or a similar runtime to identify current capabilities.