Required, optional, deferrable, and not-needed features

[NellWaliczek]

[Disclaimer: This issue is one of several being filed to capture discussions that began either on #638, on #689, or at the most recent F2F]

This one is sort a redux of a design exploration that @toji and I did many months back (see #433). At the time we were looking for a solution that would allow developers state at the time of session creation what features they absolutely need for it to be worth creating a session and which features would be really nice to have. The idea was to prevent users from having a session start only to have them be immediately told that the experience wouldn't work. Happily, this provided an opportunity for the User Agent to request user consent any of the features that the developer considered required.

I'm working on an updated concrete design proposal which shows how developers might communicate intent to use certain features yet, but in the process of putting it together, I have some questions for you all about what you'd like to see in response to that developer intent being communicated. For example:

1. Should developers be allowed to block session creation if particular "required" features are unsupported by the underlying platform?
2. If a "required" feature depends on user consent, should the User Agent prompt for consent at the time of session creation?
3. If a user does not consent to a "required" feature, should session creation be blocked?
4. If an "optional" feature depends on user consent, should the User Agent prompt for consent at the time of session creation?

[NellWaliczek]

Also related to #423 and #424

[joshmarinacci]

Is there really a difference between optional and required? From the developer perspective they ask for things and then find out what they were given, either at session start time or api use time. In either case they can render an error or show a message to the user explaining what they can and can't do now. If there was an optional type in addition to a required permission type, would what the developer does be any different? When would a developer want to actually use the optional permissions?

Second: from the user perspective would optional vs required make a difference? If you were given a dialog that says "this app wants required access to the camera and optional access to the microphone, do you want to grant it", would you reasonably be able to answer that question? If you were presented with optional microphone vs required microphone would you understand the distinction? Would you care?

I think this adds extra complexity without providing additional value.

[NellWaliczek]

Hey Josh, this really isn't about permission. It's about capabilities. And, yes, from that perspective it does make a really big difference. For example, if I'm building an AR tour guide experience, user's shouldn't have to launch the session only to find out that 'unbounded' reference spaces aren't supported by the hardware and then immediately terminate the session. However, if I'm building a VR experience that would be better with a bounded-floor reference space but actually works on an local-floor reference space it's a bit different. In this case, if 'bounded-floor' is available, I'd really prefer to ask for any necessary user consent up front, but I'll still work if it isn't granted/available.

Talking with Brandon a bit more, it seems like we probably really have four categories:

1. Required - Feature must be supported. If user consent is necessary, they will be prompted before session creation. If not present or consent is rejected, the session will not be created.
2. Optional - Feature is a nice to have. If user consent is necessary, they will be prompted before session creation. If not present or consent is rejected, the session will still be created.
3. Deferrable - Feature is nice to have. If user consent is necessary, it's up to the user agent whether to prompt at session creation or at use time (This depends on how we solve Timing of user consent requests #720, though). If not present or user consent was rejected at session creation, then the session still still be created.
4. Not Requested - Feature will not be used during the session. Attempts to use it will fail.

Now, to be clear, for each feature the default state may not actually always be "not requested". On immersive sessions, "local-floor" and "local" sort of need to be in the "required" category so that will be the case regardless of what the developer supplies.

Does that make more sense?

[avadacatavra]

@NellWaliczek wrote:

1. Required - Feature must be supported. If user consent is necessary, they will be prompted before session creation. If not present or consent is rejected, the session will not be created.
2. Optional - Feature is a nice to have. If user consent is necessary, they will be prompted before session creation. If not present or consent is rejected, the session will still be created.
3. Deferrable - Feature is nice to have. If user consent is necessary, it's up to the user agent whether to prompt at session creation or at use time (This depends on how we solve #720, though). If not present or user consent was rejected at session creation, then the session still still be created.
4. Not Requested - Feature will not be used during the session. Attempts to use it will fail.

I agree with those categories, with the addition that if a deferrable feature is requested mid-session, we must use a trusted immersive UI. I do think it could be useful to have someone chime in from a developer perspective on the differences between optional/deferrable (and the use cases they see)

[probot-label]

This issue is fixed by PR #739

[NellWaliczek]

Closed by #739