vrdisplayactivate event timing during link traversal

[kearwood]

I am implementing the vrdisplayactivate event in Firefox for the link traversal use case, which I am firing serially after the "load" event.

Does this timing of the vrdisplayactivate event make sense for the "navigation" reason? If so, I'd like to update the 1.1 and 2.0 specs to clarify the expected order of the event to state that it will fire immediately after the "load" event.

Note that this would not affect timing of vrdisplayactivate for other reason values such as "mounted" and "requested".

[toji]

The timing doesn't sound unreasonable to me, nor does updating the specs to clarify it, but I've got concerns about some related issues:

Do you intend to fire this event on every page regardless of where you were navigating from? If so I think I'd object because that'll easily (and often accidentally) be abused by sites to try and force themselves into VR mode immediately, even when that's not appropriate. If the site you are navigating from was already in VR presentation mode then I think it makes much more sense.

Additionally, we should talk about the concept of vrdisplayactivate being a user gesture. It's a convenient shorthand for discussion, but I don't think we actually want to make it a full user gesture and perhaps only allow it to act as a user gesture for the specific case of VR presentation. Otherwise, especially if paired with a vrdisplayactivate that fires on every page load, you're giving sites permission to go fullscreen, lock mouse cursors, and spawn popups immediately upon load.

Mostly we just need to concretely document the behavior around navigation in the specs to ensure that the security implications are acknowledged and that all implementations are in sync.

[kearwood]

Essentially, when a page is unloaded, the browser remembers if a VR presentation was active. If so, the vrdisplayactivate event is triggered immediately after the "load" event of the next page displayed in the same window.

If the page exits vr presentation, then follows a link, the event will not be fired on the next page.

In addition to link traversal, this applies to refreshing, navigating forward, and navigating backwards.

[toji]

That all sounds great! 👍 And thanks for pointing out that it should apply to back/forward. Hadn't thought about that yet. I'll work on spec-ifying that and put up a pull request ASAP.

What are your thoughts on vrdisplayactivate acting not as a user gesture but a targeted exception to the user gesture requirement for this single API?

[kearwood]

Regarding user gestures, I agree. It would have opened up avenues for ad popups and other undesirable scripts that would have a chance to run during the VR link traversal.

We could make it a targeted exception that expires once the vrdisplayactivate event finishes, perhaps.

[kearwood]

One other exception may be that if the browser is a VR-only web browser and no other content is presenting to the VR display (ie. following a link from a 2d page to a webvr site from inside an HMD), that the vrdisplayactivate could trigger as if it were a WebVR - WebVR link traversal.

[kearwood]

In the event of a multitasking browser where both a 2d page is being displayed (ie. as an overlay) and the environment is being rendered by another WebVR page, the vrdisplayactivate should not trigger on uri changes within the 2d page's "window".

[toji]

I think I agree in the single page, VR-browser case. That one makes me slightly more nervous, but at least it's not taking over your mobile screen and shouting PUT ME IN A HEADSET NOW! Honestly it sounds like an area where a user preference is probably desirable, or maybe a "This site would like to enter VR mode automatically in the future" infobar?

[kearwood]

I like the infobar idea. The browser could politely provide a message saying the site would like to enter VR mode automatically if it sees the hook to the vrdisplayactivate event. The user could be given options to enter VR or not (without needing to reach for the keyboard and mouse). Simple "enter vr automatically for this site" or "never ask again" options could give the user control.

If the user responds to the dialog with "enter vr", we could fire the vrdisplayactivate event with the "requested" reason, which would not have the prerequisite of occurring immediately after the "load" event.

[machenmusik]

w.r.t. user gestures, need browser support to make VR / gamepad controller actions able to generate user actions... at least for those browsers that require user gestures for various features including media playback... it is not clear those permissions should survive link traversal, but there needs to be a legal methodology to initiate without removing HMD.

[toji]

I agree that we need more consistent support for user gestures in VR controller use. In Chrome's mobile implementation, at least, clicking the Daydream touchpad will generate a "click" event on the presenting canvas (in addition to the Gamepad output), so you could fuze that with the Gamepad state to get a controller-driver user gesture.

[toji]

This issue was moved to immersive-web/webvr#21