Webxr: Use session's requested features instead of session device's enabled features to check if a reference space is supported

[MortimerGoro]

To check if a reference space is supported for a given reference space type type and XRSession session, run the following steps:

1. If type is not contained in session’s XR device's list of enabled features for mode return false.

I found some conflict between the spec explainer and the xrSession_requestReferenceSpace_features.html WPT testcase.

• According to the spec session’s XR device's list of enabled features has to be used to check if a reference space is supported for a session
• According to the testcase: Reference spaces that aren't default features are rejected when not requested as a feature, even if they have been added before to device's list of enabled features.

IIUC device's list of enabled features can contain accumulated features from multiple requestSession calls, and the spec would need to be rephrased to:

To check if a reference space is supported for a given reference space type type and XRSession session, run the following steps:

1. If type is not contained in session’s list of requested features for mode return false.

[Manishearth]

Hmm, we'll have to add such a concept, but that seems okay.

[Manishearth]

I went to fix this and realized that this is actually intentional behavior, otherwise you cannot request features be added mid-session, or request features before the session starts.

We coudl add text allowing the UA to "clear" the list of features between sessions but tbh I actually think that would result in uncertainly and isn't great.

I think the testcase should be fixed here to create a new device each time. @toji ?

[Manishearth]

So basically the existing design falls out of the following constraints:

• We want people to be able to request permissions _before_ a session starts to time prompts
• We want people to be able to request permissions _during_ a session so they need not overwhelm the user with prompts for features that may not be needed unless the user performs certain actions (like clicking an in-ui "enable experimental hand tracking" button)
• We wanted to use existing APIs as much as possible instead of inventing our own permissions system

The second one is what's biting us in particular here, we want the following to work:

let sess = await navigator.xr.requestSession("immersive-ar", { requiredFeatures: ["local-floor"]});
// ...

navigator.permissions.query({name: "xr", mode: "immersive-ar", requiredFeatures: ["hand-tracking"]});

sess.inputSources[0].hand.doSomething();

There are basically a couple paths forward for us here:

Keep it as is

The status quo is _fine_, but it does have the weird pitfall that consecutive sessions (or cached permissions) may lead to code working in some cases but not in others. It's a good way to induce "works on my machine" if the permission caching for your setup leads to code just working, but other people have sessions get rejected.

There can also be perf implications on implementations that do not spin up system resources when the relevant features are not yet enabled; e.g. ideally sessions without hand-tracking do not need to set up hand tracking until needed.

Add a mid-session feature request API

We can add a requestAdditionalFeatures({required:, optional:}) API. This is unfortunate, we built the permissions API stuff to avoid doing this. But it's probably a minor API, and the permissions API is still useful for controlling when permissions are _prompted_ vs when they are used.

Add an optional session parameter to XRPermissionDescriptor

We can continue to use the permissions API, but add a way to "tag" permissions onto existing sessions by giving it a nullable session parameter. This makes it possible for the permissions API to still be used pre-session to control prompt times, but will still be useful during the session to enable new features.

Add an optionalFeaturesIMayAskForLaterButDontPromptForThemYet parameter to requestSession()

Lets a session declare all features it _may_ rely on. Imperfect, but works. Likely to be confusing even if we can come up with a better name for it.

/agenda to discuss this next meeting

[cabanier]

I thought the permissions.query method only returned the status of a permission. It won't turn on that the feature is enabled for the session.
I looked at the permissions spec and the MDN entry but maybe I'm overlooking something.

For hand tracking, you can't turn it on mid-session since it requires a permission prompt the first time.

[Manishearth]

Ah, that's done via permissions.request() which ... doesn't exist yet. I have a vague recollection of discussing this.

This does make me want to move towards a requestAdditionalFeatures() API, then.

[cabanier]

Is there a need to have this API?

[dontcallmedom]

permission.request exists, but it has migrated to a separate API in incubation given lack of consensus on the approach https://github.com/WICG/permissions-request

[Manishearth]

Is there a need to have this API?

I believe the ask was so that content can request features mid-session so that they don't have to request everything upfront in case the features used depend on user choices.

[Manishearth]

Actually I can't find the issue asking for that. Hmm

[Manishearth]

Opened https://github.com/immersive-web/webxr/pull/1189

I also filed https://github.com/immersive-web/webxr/issues/1190 as a followup, but it does not need to block CR.