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:
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.
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.
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:
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 towindow.location.href
(and we could even immediately project to the stereo container without waiting formozbrowsermetachange
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 (à lapushState
/replaceState
). so I'd hate to rely on having developers manually changewindow.location.protocol
or usingpushState
/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:
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