MozillaReality / horizon

(2015) Horizon was an experimental VR browser built on web standards using CSS-VR.
http://mozvr.github.io/horizon/web/
Other
1 stars 0 forks source link

VR mode is not correctly entered when a mono site requests fullscreen #189

Open cvan opened 9 years ago

cvan commented 9 years ago
  1. navigate to a classic mono web page that has some WebVR content that's accessible when entering fullscreen mode.
  2. enter fullscreen (on some VR container).
  3. notice Horizon doesn't re-project the site in stereo VR mode, because it still thinks we're on a mono page.

when the view-mode projection changes, Horizon needs to know.

to get the mozbrowsermetachange event to fire, Horizon needs to knows the viewmode has changed.

if Horizon loads a page that has projection=mono (or has no <meta name="viewmode"> tag at all), we assume a mono view-mode projection for the rest of the duration of the page. but when the user has requested full screen on its main VR container, that is technically supposed to now be stereo VR mode.

but we'd never know unless the developer changes the viewmode, by dropping in/swapping in this tag:

<meta name="viewmode" content="projection=stereo">

IMO, it'd be a poor developer experience if we required content to start doing manually entering these tags so things just work correctly.

ideally, we stop overloading fullscreen as VR mode. and then the developer would just call some browser API named like requestVRMode - and everything would be peachy.

the hack that would work today is whenever there's a mozfullscreenchange event (presumably whenever a mono page enters full screen, and we know with some certainty it's a change to VR mode), we could manually redirect to window.location.href (and we could even immediately project to the stereo container without waiting for mozbrowsermetachange if we wanted).

if we can go with the http+vrstereo (?) protocol (like we revisited our discussion of at Whistler; issue #185), hopefully we can just have people redirect/change the protocol of the URL, and handle it there. but I can imagine there being cases when you want to gracefully toggle between the two without causing a synchronous page refresh (à la pushState/replaceState). so I'd hate to rely on having developers manually change window.location.protocol or using pushState/replaceState to trigger viewmode changes after the main document has been loaded.

it sounds like we need a technique similar to how good ol' frame busting works:

if (window.self !== window.top) {
  window.top.location = window.self.location; 
}

alas, the <iframe mozbrowser> element doesn't know it's an iframe and therefore can't bust. nor can the iframe communicate with its parent (i.e., Horizon); see issue #120 and bug 1171237.

ideas (and hax :hammer:) welcome.


parent issue: #120

cvan commented 9 years ago

relevant: WebVRManager.prototype.enterVR

cvan commented 9 years ago

We should talk to B2G/DOM folks about adding an mozbrowserfullscreenchange event that fires with vrDisplay so Horizon can identify that VR mode has entered.

Related: #120.