Proposal: lower friction to enter WebXR sessions

[cabanier]

Today WebXR sessions are almost exclusively started when the user clicks a button. The button typically indicates AR or VR and is enabled when the site is ready to start the session. If the user clicks on the button, its event handler executes requestSession and the immersive session begins.

We have noticed that this workflow is not always very smooth. Each website has its own way of entering VR: buttons have different shapes and colors and are in different places on the page. Sometimes the website was designed for a larger window so the button is no longer in view which is very confusing to users.

To work around this, we'd like to propose a new WebXR API that the site can call when it is ready to enter AR/VR. After making this call, the browser will have a render VR/AR button in its interface. When the user clicks this button, the session will kick off as usual.

I suspect that this API will be very similar to RequestSession and that we need another API to deregister the button from the browser interface.

[cabanier]

/facetoface

[josh12451]

https://user-images.githubusercontent.com/32694595/164360301-133c1efb-978c-4884-8417-2c2efdb4c273.mov

Attached is a video showing how we could optimize the browser entry experience given this API

[vicpon]

If I'm understanding this correctly, you're suggesting that the "Enter VR" button should be rendered by the browser. Personally, I hate the native dialogs browsers use. They cut into the UX like a rusty knife. They look very out of place with the rest of your flow.

[Manishearth]

Results of some discussion with Rik:

The main tricky bit here is rejection, because it's unclear when offerSession() should reject.

I see a divergence of user experiences based on whether you're on an XR device or on a desktop system with an XR device connected (or not yet connected!). When on an XR device, the experience is rather straightforward: there's no reason to not always show the chip as long as things are compatible, and you click it if you want to enter XR, and the offerSession() promise need never reject. The system might have an "are you sure?" prompt but it need not reject the promise if it's declined, the user may want to press it later. It might reject immediately if you request a feature that's unavailable on the current device.

On the other hand, on a desktop system. we have two broad choices:

• Immediately reject offerSession() if devices aren't connected / incompatible with the request. This has fingerprinting issues and doesn't handle the case where a user has a device that isn't connected.
• Only reject if requestSession() rejects. This is similar to the Oculus case, except Oculus has a clearer idea of system capabilities from the get-go

In general we prefer the second option. The UA can even detect when the session would be rejected outright and just say "hey you don't have a compatible device" so that the user can plug one in without the promise being rejected.

One workflow that doesn't work is if you have the wrong device plugged in, user clicks the chip, promise gets rejected, and chip goes away (because without a promise to tag onto it's pointless). I think that's fine, user can reload the page or interact with an on-page "enter vr" element.

We also probably want there to be a way for the user to right-click dismiss the chip, non-normatively.

[cabanier]

Quest browser is running this as an experimental feature and I need some clarification on behavior:

• what happens if the offerSession call is made more than once?
• how does it work with iframes?
• should there be a call to cancel an outstanding offerSession promise?
• it's a bit odd that the author has to call offerSession again after going immersive. Should we leave this to user education?

/facetoface clarify offerSession behavior