Devsite demo doesn't work in iOS

[googlearchive]

Devsite demo doesn't work in iOS

[borismus]

This should be fixed.

[tucson-tom]

Unfortunately, the VR demo is not fixed. The display, while no longer pointed at the ceiling, is now frozen at 0 yaw. Full screen mode is now broken and does not enter full screen. Cardboard mode in the demo is also broken, which is probably related to the full screen issue. Touch is improved but not smooth and doesn't accurately follow the movement (e.g. rotating the screen and applying touch movements). The display still does not follow the user's movements at all and requires touching the display. For comparison, the demo on Android + Chrome works flawlessly, following the motions of the user in all cases. Both Safari and Chrome on iOS still have serious issues. Clearing the web browser's cache does not help.

[rosserl]

the issue title is a little bit misleading as it's not only the devsite demo that is not working, ios gyro / fullscreen is broken generally

[tucson-tom]

@rosserl When you say "broken generally", do you mean that there are (unfixable) bugs in iOS in general or are you just referring to this repo?

[rosserl]

no actually i was a little bit mistaken, because i had the vrview inside an iframe, just as the devsite demo does.

but i did some research, it's actually two different issues which have nothing to do with each other, and yes you could kind of say, ios safari is broken =)

1. fullscreen: as ios does not support html5 fullscreen api, vrview works around that with that iframe-pseudo-fullscreen-css. now that works just as intended when not inside yet another iframe, but inside another iframe of course it only goes to full outer iframe size. on the devsite demo there's an iframe having src = https://google-developers.appspot.com/vr/concepts/vrview_7220055d5f6acdb547c071c927f216b1.frame?hl=de and there another iframe (the good, resizable one) gets injected. (having src = https://storage.googleapis.com/vrview/2.0/index.html?preview=//storage.googleapis.com/vrview/examples/coral-preview.jpg&image=//storage.googleapis.com/vrview/examples/coral.jpg&is_stereo=true&)
   so this basically can only be fixed if the second iframe is used directly on the devsite demo page (or maybe by not injecting an iframe in step2 which is not realistic)

2. gyroscope: that's that: https://bugs.webkit.org/show_bug.cgi?id=152299 - ios safari does not allow gyroscope access in cross-origin iframes since ios 9.2
   so this could be fixed only by putting the iframe source on the same domain as the host page (or weird hacks)
   this is actually the bigger issue, as at the same time, again ios only, the vrview code has to be hosted on the same domain as the video, so if you want the gyroscope working and videos, you would have to have the website, the embed code and the video on the same domain.

[borismus]

You're right... :(

Looking more into this, it's a break in iOS 9.2. Previously (iOS 8), devicemotion events weren't transmitted to iframed pages. So we solved it using device-motion-sender/device-motion-receiver. But as of 9.2, even registering for the devicemotion event inside an iframe is prohibited:

Blocked attempt add device motion or orientation listener from child frame that wasn't the same security origin as the main page.

For now the unfortunate workaround is to self-host the VR View code on the same domain. We could in theory do something like intercept the transmitted devicemotion events and feed them directly into the polyfill.

[borismus]

I've just updated the polyfill to respond to the synthetic devicemotion events, and it works fine in general (eg. http://smus.com/vr-view-2.0/). Unfortunately the way devsite works is that it iframes its entire contents.

So devsite is hosted at (1) https://developers.google.com/vr/concepts/vrview, but it iframes (2) https://google-developers.appspot.com/vr/concepts/vrview-web_7220055d5f6acdb547c071c927f216b1.frame?hl=en, which then iframes (3) https://storage.googleapis.com/vrview/2.0/index.html. Turtles all the way down.

Anyway, since (2) is already iframed, the attempt to listen for devicemotion events is thwarted. This is as far as I'll hack. We're going to need a cleaner solution to the original problem: https://bugs.webkit.org/show_bug.cgi?id=152299