Support UAs having a method to enter/exit immersive mode directly

[blairmacintyre]

The idea of having the UA present mechanisms to the user to enter/exit immersive mode has been brought of a few times, most recently in https://github.com/immersive-web/webxr/issues/411 (when closing that issue, @NellWaliczek suggested we open a separate issue for this).

To enable this, the session creation flow should probably be changed to not use promises, but instead to trigger events when the session is created. The flow shown in the examples wouldn't change significantly (since the promises are simply calling a method, analogous to what would happen with events). The methods could continue to return promises, if that is desired as a way of returning success or failure; but the act of entering immersive mode should trigger the events asynchronously.

[cwilso]

I think the methods should continue to return promises even if we add events to be triggered. This is common modern web API design practice.

[blairmacintyre]

I am not sure I agree, I admit, although we might be saying the same thing. (I think promises are great, for situations where there is going to be one-and-only-one answer.)

In this specific case, if there can be multiple answers, the "other" pattern (events) should be used.

Now, it may be that the requestSession returns a promise as a way of indicating if the requested features (esp the "required" features) are possible; if the request session fails, having a promise to capture that is good.

If the session will be launched, it could still fire the event, and could also trigger a successful return on the promise.

The thing I want to avoid is having web-apps that only support "entering XR" once, because they have a linear promise-based flow.

[paulrouget]

Servo might need something like that at some point. We would like the UA to tell the web app "it's time to enter immersive mode".

I'm not sure if the JS callback would be in charge of creating the session or if the session would be created by the UA.

[blairmacintyre]

If you really want to support UA triggered session creation cleanly, I think the UA needs to create the session -- otherwise, the user could request something, and then something different gets requested by the page, and the user is presented with something different ("I requested AR, and got VR?"). As soon as you put the page in charge of session creation, it's impossible to cleanly implement this, because the page is in the loop.

It feels like co-operative multitasking. It works fine in theory with well-behaved apps, but is destined for failure in the real world, because real people don't actually write well-behaved apps.

I've pushed for UA controlled creation years ago, with the goal that pages could request features, but the UA would be entirely in change of going immersive (pages might request immersive mode with a simple event in response to user-action, but the configuration of their preferences, and the handling of session creation, would be completely separate).

The community has always been completely against this, for reasons I admit I still don't understand. It will prevent us from using WebXR to get to a real "immersive web" as opposed to "immersive pages".

Although, perhaps that's fine. Perhaps eventually, "webxr+webGL canvas" will be the moral equivalent of "canvas" and we'll have a whole separate set of declarative APIs that implement the actual immersive web.