search

immersive-web / cardboard-vr-display

A JavaScript implementation of a WebVR 1.1 VRDisplay
https://immersive-web.github.io/cardboard-vr-display
Apache License 2.0
92 stars 43 forks source link

After exiting WebVR, rotating on wrong axis in Firefox #15

Open jsantell opened 6 years ago

jsantell commented 6 years ago

STR on Pixel, Firefox for Android, 57.0.4:

Can go to landscape while in VR and back to portrait after exiting, same result. Happens with or without the changes in #13.

Update: When rotating to enter VR, the orientation screen transforms are never updated in fusion-pose-sensor, and neither subsequently triggered as no orientationchange events fire, so the screen transform is stuck in VR orientation: https://github.com/immersive-web/cardboard-vr-display/blob/082c54f1390534b3d3da29c98864adf38864acdc/src/sensor-fusion/fusion-pose-sensor.js#L200

Could be a platform issue?

cvan commented 6 years ago

@bluemarvin @snorp have you seen this issue on Firefox for Android? I can file a Bugzilla platform issue, but I figured y'all might have some insights as to what's going on here

jsantell commented 6 years ago

Looks like this has been an issue for a long time, can reproduce on older and recent A-Frame demos as well. Not 100% confident in the issue being orientationchange events firing without a stripped down test case, but reproducible enough

jsantell commented 6 years ago

Some updates:

Trying to recreate a minimal test case using fullscreen and orientation lock, but can't seem to reproduce the issue we're seeing in CardboardVRDisplay.

Separately, when testing the local demo, it looks as if the handlers are frozen after returning from "VR" (fullscreen) mode. Put a breakpoint/console.log in the orientation change handler in the FusionPoseSensor to indicate when the change is detected. This will no longer fire after returning from "VR" mode. With devtools open (via WebIDE), bind another orientationchange event:

window.addEventListener('orientationchange', e => console.log('change');

Now, rotating the device, we'll get the original FusionPoseSensor orientationchange event, as well as our new one we added via WebIDE, as if binding a new event after "VR" mode "unfreezes" the orientationchange events.

This is very weird. @cvan is the above STR sufficient enough for filing a platform bug? Disappointed that the stripped-down test case still cannot reproduce the issue, so maybe there's another platform API that's possibly interfering here, but not sure what to make of the event breaking, and becoming re-enabled when binding another event subsequently. :expressionless: