{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/webvr/issues/30","repository_url":"https://api.github.com/repos/w3c/webvr","labels_url":"https://api.github.com/repos/w3c/webvr/issues/30/labels{/name}","comments_url":"https://api.github.com/repos/w3c/webvr/issues/30/comments","events_url":"https://api.github.com/repos/w3c/webvr/issues/30/events","html_url":"https://github.com/w3c/webvr/issues/30","id":158027042,"number":30,"title":"Linking between VR web pages","user":{"login":"cvan","id":203725,"avatar_url":"https://avatars.githubusercontent.com/u/203725?v=3","gravatar_id":"","url":"https://api.github.com/users/cvan","html_url":"https://github.com/cvan","followers_url":"https://api.github.com/users/cvan/followers","following_url":"https://api.github.com/users/cvan/following{/other_user}","gists_url":"https://api.github.com/users/cvan/gists{/gist_id}","starred_url":"https://api.github.com/users/cvan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cvan/subscriptions","organizations_url":"https://api.github.com/users/cvan/orgs","repos_url":"https://api.github.com/users/cvan/repos","events_url":"https://api.github.com/users/cvan/events{/privacy}","received_events_url":"https://api.github.com/users/cvan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2016-06-01T23:09:02Z","updated_at":"2016-06-01T23:09:35Z","closed_at":null,"body":"<a href=\"https://github.com/brianchirls\"><img src=\"https://avatars.githubusercontent.com/u/492291?v=3\" align=\"left\" width=\"96\" height=\"96\" hspace=\"10\"></img></a> **Issue by [brianchirls](https://github.com/brianchirls)**\n_Thursday Mar 17, 2016 at 15:09 GMT_\n_Originally opened as https://github.com/MozVR/webvr-spec/issues/22_\n\n----\n\nI seem to recall some discussion of enabling linking directly from one VR web site to another without having to stop presenting. The spec as it is doesn't seem to handle that.\r\n\r\nThis is a potentially tricky case, so I understand wanting to hold off on implementation until more progress is made in the field. But has there been any discussion about what this might look like in an API? Are we confident that the API as it currently stands leaves room for that in the future?\n"},"comment":{"url":"https://api.github.com/repos/w3c/webvr/issues/comments/223151656","html_url":"https://github.com/w3c/webvr/issues/30#issuecomment-223151656","issue_url":"https://api.github.com/repos/w3c/webvr/issues/30","id":223151656,"user":{"login":"cvan","id":203725,"avatar_url":"https://avatars.githubusercontent.com/u/203725?v=3","gravatar_id":"","url":"https://api.github.com/users/cvan","html_url":"https://github.com/cvan","followers_url":"https://api.github.com/users/cvan/followers","following_url":"https://api.github.com/users/cvan/following{/other_user}","gists_url":"https://api.github.com/users/cvan/gists{/gist_id}","starred_url":"https://api.github.com/users/cvan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cvan/subscriptions","organizations_url":"https://api.github.com/users/cvan/orgs","repos_url":"https://api.github.com/users/cvan/repos","events_url":"https://api.github.com/users/cvan/events{/privacy}","received_events_url":"https://api.github.com/users/cvan/received_events","type":"User","site_admin":false},"created_at":"2016-06-01T23:09:35Z","updated_at":"2016-06-01T23:09:35Z","body":"<a href=\"https://github.com/cvan\"><img src=\"https://avatars.githubusercontent.com/u/203725?v=3\" align=\"left\" width=\"48\" height=\"48\" hspace=\"10\"></img></a> **Comment by [cvan](https://github.com/cvan)**\n_Thursday Mar 24, 2016 at 01:48 GMT_\n\n----\n\n> So how does the destination web page know that it's already presenting when it starts running?\r\n\r\n> And what happens if that destination web page doesn't know how to handle VR?\r\n\r\nLast summer, we prototyped a standalone VR backwards-compatible browser based on Firefox's Graphene project (which is Desktop B2G, similar to Electron). You have an app manifest, an `index.html`, and your scripts which have access to special APIs (which you can use obviously to create your own application – or browser! – in HTML+CSS+JS). [Check out the MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API), if you're interested. It's quite similar to Chrome's Content API for its webviews.\r\n\r\n[Check out this short video demoing our Horizon prototype browser.](https://vimeo.com/157952401)\r\n\r\nÀ la the `meta[name=viewport]` tag, we added a `meta[name=viewmode]` tag (see [code in Firefox here](\r\nhttps://dxr.mozilla.org/mozilla-central/search?q=viewmode+path%3Adom%2Fbrowser-element&redirect=true&case=false\r\n)). This is really only useful for Graphene-based apps which can listen for mozbrowser-specific events such as `mozbrowsermetachange`.\r\n\r\nUnlike the `viewport` tag, `viewmode` does not block. This meant that we wouldn't know exactly when a page loaded whether it would be a full VR experience, a 2D classic/mono experience, a 2D experience that also has a button to enter VR mode, a 2D-to-3D VR responsive experience, a 2D+3D+mobile+desktop responsive experience, etc. It gets complicated.\r\n\r\nAnd you want to know which type of experience it is before you render the next page. Do you project a non-VR site as a 2D plane? That's what we did with Horizon. That isn't doable in content with pure WebGL in Chrome, however. \r\n\r\nWe looked into the [Navigation Transitions spec](https://docs.google.com/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit) ([good critique blog post here](http://chrislord.net/index.php/2015/04/24/web-navigation-transitions/)) or writing an extension or chrome-level code in Firefox that would allow a kind of hijacking/pausing of the navigation. Navigation Transitions isn't fully spec'd or implemented in Chrome nor Firefox, so that seemed premature to count on that.\r\n\r\nChrome versions 31-38 used to rely on [`<meta name=\"mobile-web-app-capable\" content=\"yes\">`](https://developer.chrome.com/multidevice/android/installtohomescreen#fallback) to identify whether a web site was a \"web app\" that could be added to the homescreen. (As I'm sure you know, Safari for iOS have their own [Apple-specific meta tags](https://developer.apple.com/library/iad/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html), which was the inspiration for this `mobile-web-app-capable` one.\r\n\r\nAnyway, Chrome for Android 39 stopped using the `mobile-web-app-capable` meta tag. Instead, \"web apps\" are defined as sites with a manifest and a Service Worker.\r\n\r\nThat's when I proposed using the [Web App Manifest](http://w3c.github.io/manifest/) for VR-specific metadata. It seems like a good idea because you can reference a single manifest for all documents on your server (e.g., suppose you have a VR world that contains a different document per level). Huge plus would be not having to propose and invent a new `<meta>` tag for each new WebVR feature we want to support.\r\n\r\nExample: Michael Blix at Samsung had proposed a [`meta[name=\"vr-background\"]`](https://gist.github.com/m-blix/5ef47b24dbd24782256d) (à la [`meta[name=\"theme-color\"]`]). This would be a perfect case for using a key in the manifest.\r\n\r\nSince the [Web App Manifest spec has a non-normative section suggesting to use proprietary keys](http://w3c.github.io/manifest/#proprietary-extensions), the browser could use that information to identify the viewmode of the site and then figure out the projection. Or if a 2D page is encountered, the user agent could decide to open that in a new tab and display a notification message in the headset. It's really up to the user agent to decide how to handle \"legacy\" content. But parts of this probably ought to be spec'd, at the very least as non-normative text in the spec.\r\n\r\nThe Manifest spec is [explicit](http://w3c.github.io/manifest/#obtaining) that manifests should be `fetch`ed asynchronously by the browser. So obviously fetching and reading the manifest metadata would slower than synchronously parsing a `meta` tag. \r\n\r\nIf you're interested in some of the pros/cons of the approaches the Mozilla VR was doing WebVR prototyping and prepping for the WebVR API overhaul for v1.0, check out this [Google Doc](https://docs.google.com/document/d/1flF_0gyCeNL6CJoIQWDvq0vRs894AP5Ycad-pokLemI/edit).\r\n\r\nAnd, heh, I just found [a short summary](https://gist.github.com/cvan/34723d11947a11a09048) I wrote a few months ago that mostly summarises what I said above.\r\n\r\nAnyway, we stopped working on our Horizon browser prototype because of a bunch of technical limitations:\r\n\r\n- we were not using pure WebGL but an experimental Firefox branch of [CSS-VR](https://people.mozilla.org/~vladimir/vr/simple-css-2.html) for the HUD and projecting planes (CSS-VR turns out was too slow - and not to mention scary and risky because we were overloading CSS properties)\r\n- backwards compatibility was costing us a lot of time (Firefox didn't support [spatial navigation](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/TV/TV_remote_control_navigation) at the time; so we were going off some unimplemented W3C spec and writing our own solution using HMD gaze-based cursor + gamepad controls for clicking and tabbing between focussable elements)\r\n- we had to propose a lot of Chrome-level changes to support VR experience using the `mozbrowser` API, and we couldn't at the time justify that these changes would amount to an experience we wanted; another option was to fork Firefox and strip out the UI ourselves, but maintaining a fork is costly and risky\r\n\r\nWe should loop in @caseyyee from the Mozilla VR team who has done a lot of thinking with me on the browser and link traversal UX prototyping. Also, we should loop in @mkeblx from Samsung. The Samsung Internet Browser for Gear VR has to handle all of these things in the very near future, as they're looking to support first-class legacy 2D and WebVR experiences.\r\n\n"}}
{"actor":{"display_login":"cvan"}}