[webvr] Why does entering VR need to be on user interaction?

Chris Van Wiemeersch cvan at mozilla.com
Fri Sep 23 03:56:17 UTC 2016


On Thu, Sep 22, 2016 at 7:28 PM, Cécile Muller <contact at wildpeaks.fr> wrote:

> Hi list,
>
>
> Quick idea: if the link can specify the target should open directly in VR,
> how about using the existing "rel" attribute, e.g: <a href=".." rel="vr"> ?
> It's already meant for keywords describing the link type:
> https://www.w3.org/TR/html5/links.html#linkTypes
>

Our VR team at Mozilla did a ton of browser prototyping last year. We
thought about custom protocols (e.g., vr://, stereo://, https+vr://,
https+stereo://), `<meta>` tags, response headers, etc.

For a walk down memory lane, check out Josh Carpenter's awesome post that
runs through all the different browser prototyping our team did:

    http://www.joshcarpenter.ca/vr-browsing-explorations/

Based on tech previously used for Firefox OS browser development, we built
a custom headless version of Firefox that was a VR-first browser that we
could iterate on quickly using just HTML, CSS, JS, and content scripts à la
Greasemonkey scripts to inject JS code into the HTML document (which we've
been meaning to open source and write a blog post retrospective on).

And, here's a quick video capture of that VR-first, classic/2D
backwards-compatible browser in action:

    https://vimeo.com/157952401

Anyway, this is how we handled entering VR and link traversal:

1. For sites that should enter VR automatically, you can define `<meta
name="viewmode" content="projection=stereo">`, but we assume that sites
will be stereoscopic (VR) by default and when we parse the HTML we get a
trusted event from the `mozbrowsermetachange` browser (à la
Chrome/Electron's <webview> API) that we can use to identify whether when a
`viewmode` tag is added/changed/removed and act accordingly. If a site is a
classic/2D/non-VR site you would define `<meta name="viewmode"
content="projection=mono">`. And, when we see that, we drop out of VR mode
and project the site as a 2D plane in front of you. During that time, all
we had available were Oculus Rift DK2s and Xbox controllers. We implemented
spatial-focus navigation (see https://www.w3.org/TR/css-ui-3/#nav-dir,
https://www.w3.org/TR/WICD/#current-focus-point-algorithm,
https://gist.github.com/cvan/343ab139223f3b5dd2cc,
https://github.com/medialize/ally.js/issues/65,
https://github.com/Flamefork/freefocus, and
https://davidwalsh.name/spatial-navigation for context). So, you could tab
between `tabindex`-able elements using the D-pad, scroll using the left
joystick, click clickable elements (e.g., links and buttons) using the
Xbox's X button, and bring up a HUD that showed a grid of favourites
populated from a JSON file and a text field containing the current URL (but
you needed to type in a URL using your keyboard). We also supported
multiple controllers in the wild too, not just the Xbox controller.

2. If you had a 2D site that wanted to enter VR mode upon a user action or
some login screen for example, you could imperatively call
`requestFullscreen({canvas: webglCanvas})` (or now
`navigator.getVRDisplays()`). When `navigator.getVRDisplays()` resolves,
you could choose which VR device you want to use to present and then call
`vrDisplay.requestPresent()` to enter VR mode.

3. If you wanted a more speedy presentation of VR mode and you had access
to modify the response headers of your HTML pages, you could set a response
header of `X-Viewmode: stereo` and the browser would know to enter VR mode
even more immediately than it would using a `meta[name=viewmode]` tag.

A lot of this was inspired from `meta[name="viewport"]` which mobile
browsers use to define the width and scale of the site. Also, the response
header bits were inspired by the still-influx Navigation Transitions API
proposed by folks at Google (
https://docs.google.com/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit
).

For posterity's sake, below are some links to several of our brainstorming
documents concerning VR browsing and link traversal:

https://docs.google.com/document/d/1flF_0gyCeNL6CJoIQWDvq0vRs894AP5Ycad-pokLemI/edit
https://docs.google.com/document/d/1dmwsWpC-pYMV30Zb4B9Ikkxtz5ho1tVTT8Z-VR-ACGg/edit
https://docs.google.com/document/d/1VuPyvXFpW1NizxtNms5ByY0GULESyLtQwKAqK5GGFF4/edit
https://docs.google.com/document/d/146GeLBVEbuxSkWFNJsn0up6QZaHjfEaWXveaObJieB4/edit
https://docs.google.com/document/d/1oWOqwMm8UxjfV73molyGAGKclueIkMyTXk1-MNfx1Y4/edit
https://docs.google.com/document/d/1KVT6phdxiqhZA97F92OwyZdztc7gONeb00bNM0dI2x8/edit
https://docs.google.com/document/d/1qlxbB620jv16my85ked0ZV99Pdiy9kJ6gk_5q59tl8Q/edit

Hope some of this is of use to folks in (re)thinking how to achieve
adequate browser navigation and link traversal in a WebVR context.


> See you,
> Cecile
>
> 2016-09-22 23:16 GMT+02:00 Leonard Daly <web3d at realism.com>:
>
>> Advertisers have gotten very good at getting their information in front
>> of users. I remember all of those Flash ads there were really obnoxious and
>> annoying. Things would popup (or enlarge) on mouseover. One site did a
>> "page turn" animation on the real content to reveal an ad.
>>
>> If there are multiple VR ads on a page in addition to real VR content;
>> how is the system going to communicate to the user which VR content is
>> asking for permission to go immersive?
>>
>> Same question applies for VR-to-VR link and (currently being discussed)
>> HTML-to-VR link.
>> (BTW, a use case for the latter might be a catalogue site to entrances to
>> various VR environments. Once inside the environment there would be
>> VR-to-VR links).
>>
>> It might be possible to have a META tag reference a specific ID that has
>> pre-approved (in some manner) permission to go immersive. That way nothing
>> else on the page would be able to jump in ahead of it in the queue.
>>
>> Whatever method is chosen, it needs to be something that an advertiser
>> cannot usurp (e.g., by dynamically changing the DOM).
>>
>>
>> On 9/22/2016 1:39 PM, Brandon Jones wrote:
>>
>> It wouldn't get fired off into iframes or anything like that, so it would
>> require some level of cooperation from the page, but sure. That would
>> basically a VR interstitial. *shudder* Not my idea of a good time, but the
>> key here is that it didn't unexpectedly kick the user into a whole new
>> state. They were looking at immersive content, and have now transitioned to
>> a new set of immersive content, and maybe it's not the one that they were
>> expecting but it's less jarring by far than if they had been looking at a
>> 2D page in a VR browser and are suddenly plonked into PepsiWorld without
>> warning. (Or, of course, were looking at a page on mobile and for reasons
>> beyond their comprehension are now looking at a split screen distorted view
>> of PepsiWorld.)
>>
>>
> _______________________________________________
> web-vr-discuss mailing list
> web-vr-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/web-vr-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/web-vr-discuss/attachments/20160922/321b7594/attachment-0001.html>


More information about the web-vr-discuss mailing list