[Explainer feedback] Page navigation

[travisleithead]

Was reading the explainer today, and got to the section about page navigation. The use case of wanting to continue a VR experience through a navigation seems like a good idea, but accomplishing it using the way described sounds very challenging.

For navigations within an origin, this may make a lot of sense, where there is clear continuity of experience due to orchestration of all the pages in question by the maintainer of the site's origin (which of course isn't guaranteed). However, when thinking about continuing an experience between unrelated origins, this starts to seem far-fetched that there is really any continuity to be had. Perhaps the idea is only to quickly re-use a previously established hardware and configuration setup?

In addition to continuity, I am concerned about potential privacy and security leakage of any shared state between origins that may be assumed in such a design.

There are other implementation concerns that come to mind for the process model if a session's data is to be preserved and re-surfaced in a new navigation...for example, it may make it difficult or impossible to segregate sites by process (process isolation) without unnaturally delaying the outgoing page's navigation until the incoming page's required event is raised.

I think there are plenty of alternate ways in which session resumption could be accomplished without introducing the proposed event. Features like sessionStorage to store state and coordinate data between navigations, pushState and HTML5 history navigation to simulate a navigation without actually triggering a full navigation, even using shared resources like IndexedDB, SharedWorkers, ServiceWorkers, or some other mechanism. In most all of these scenarios you must have coordination between source and target of navigation--and these are the cases where continuing a WebVR session across navigations makes sense to me. Otherwise, I admit that I just don't think this is a good idea.

(And in light of Issue #200, I think this section runs the risk of overshadowing other feedback that might be more relevant or useful to your group.)

If you continue down this path, consider that you may want to get web servers involved in the navigation flow (to help facilitate a faster hand-off than waiting for the subsequent page to load and run script), so adding headers or something else to let them know what's desired as part of the navigation. Also, consider how this will need to integrate with CSP, Feature Policy, and other policy mitigations that each side may want to throw up to restrict this from happening.

Thanks!

[toji]

Thank you for your comments! I think there's at least one fundamental misunderstanding at play here, but this is the type of thing that requires extremely careful consideration and so it's a good conversation to have.

Perhaps the idea is only to quickly re-use a previously established hardware and configuration setup?

This is the primary concept we want to allow, yes. Let's assume for the moment that in at least some circumstances (at least same origin) we want to allow a user to stay "in VR" between pages. This requires, at minimum, for the newly loaded page to:

1. Have a way to recognize the user wants to be in VR. It would be a mistake to allow activation of VR mode at any arbitrary time, or on every page load, so we need to communicate when it's appropriate. That probably means "The page the user was on previously had an active VR session when they left." Hence the proposed navigate event.
2. Know which device to use. If the user has multiple headsets connected to a single machine (rare, but I've done it!) they'll be really annoyed if they leave a page and the next one lights up the headset on their desk rather than their head. If we have an event, it seems ideal to communicate this as an event property.
3. Know broadly "how" the previous page was using the headset. In the explainer I tried to communicate this as "This event provides... a VRSession that's compatible with the one the previous page was using." which is a bit abstract, and probably the source of our miscommunication. I definitely don't mean that the session itself should be passed between pages, nor that we attempt to duplicate the previous pages layout or even guarantee that the tracking data will be consistent between pages. It simply means that the session provided to one page is similar enough to the previous page's session that you could conceivably carry out a basic fade-to-black-and-back transition between the two. For example: Let's say that we support both Cardboard and Daydream VR. Both are technically a single "device" but with subtly different display properties. We don't want to be on a page that is presenting via Daydream's presentation pipeline and then transition to a new page that, for whatever reason, starts using Cardboard's presentation pipeline. That's an implementation detail that doesn't require any script-visible state to be shared, but the explainer/spec should specify that's the case.

Obviously we need to find some better (hopefully concise) language to describe all that, to avoid confusion on the same points you listed.

Beyond that, I'd argue that the WebVR spec is entirely uninterested in the mechanics of any attempt to maintain visual or temporal consistency between pages. I can see interesting use cases for communicating user coordinates between pages, but you've already pointed out a variety of existing ways that could be accomplished. This is definitely a place where I'd prefer to see the web ecosystem come up with it's own protocols rather than us guessing at the eventual needs and baking bad assumptions into the browser forevermore.

So I hope that answers your concerns. I feel like we're probably largely on the same page here, with the breakdown being insufficient explainer explanation. ;) Suggestions for verbiage that would have made this clearer to you would be appreciated!

[toji]

Updated the related section of the explainer, BTW. https://github.com/w3c/webvr/blob/master/explainer.md#page-navigation

[toji]

Ping! @travisleithead, I'd like to know if I've addressed your concerns or if there's some aspect of your feedback I've overlooked.

[toji]

We should be very careful about the spec language around this feature, but lacking additional feedback I'm going to consider this concern to be addressed and close the issue.

[travisleithead]

Thanks for the extra details and thoughtful response. Naturally, there's still a lot of details to work out.

I still have a vague sense of uneasiness about the approach. The desire to "stay in VR" across navigations, while reasonable, seems to be wrongly inside-out to me. It sounds like your ideal is to connect the web browser's presentation surface (a tab? multiple tabs?) to a separate VR presentation surface and "browse" from inside that experience. In this experience the setup and connection would be done outside the scope of a particular web page experience.

The way you are proposing to do this (via an event), lacks the appropriate signals and handshakes between the two pages (the outgoing and incoming pages). It would make much more sense to me, if there was a way for the outgoing page to indicate that the VR session should be "stashed" or "suspended" (at least the device-in-use and related info--not the WebGL content, etc.). Then, optionally, the incoming page could "resume" use of that VR device if it wished to. Such a scenario would also work for the same page, if it were refreshed, for example (it could avoid the setup logic if it detected that there was a stashed VR session). Naturally, privacy/security concerns come to mind with this.

The other specific concern I have with the event is that a handler must be registered for this event in order to "catch" it. Depending on the timing of when this event might be fired (which I assume is very early in the loading pipeline if you don't want the "fade-to-black" experience to wait at a black view for a long time), the web developer might miss the registration point. Specifying the timing of this event may also be very tricky. Probably an event is not the right paradigm for what you're after. :)

[toji]

Re-opening, since it's obvious there's still some productive conversation to be had on this subject.

It would make much more sense to me, if there was a way for the outgoing page to indicate that the VR session should be "stashed" or "suspended"... Then, optionally, the incoming page could "resume" use of that VR device if it wished to.

I'm not sure I grok the benefit of having the outgoing page grant permission to the destination to stay in VR or not. I guess that's roughly analogous to a link specify something like target="_blank" to have a bit more control over the navigation. I guess the big question is "are there scenarios where the outgoing page would want to specify that they wanted to navigate to a 2D version of a site rather than any VR version it may support."

Worth noting that in a world where the handshake isn't explicit the page could still trigger that mode by closing the VR device session and then navigating.

The other specific concern I have with the event is that a handler must be registered for this event in order to "catch" it... Probably an event is not the right paradigm for what you're after. :)

This is one of my biggest ongoing concerns with the feature. I was having a conversation about it just yesterday, actually, and we came to the conclusion that a promise may be more applicable here to catch this type of "one shot event". That doesn't totally solve our timing problem, though, since we would want to fall back to the 2D view of the page if the page isn't going to handle the VR transition, and that implies that we have to have some sort of timeout. Really just not sure how best to handle that.

[NellWaliczek]

Tracking page-to-page navigation behavior in #382 and #383. Closing as part of repo cleanup