After exiting WebVR, rotating on wrong axis in Firefox

[jsantell]

STR on Pixel, Firefox for Android, 57.0.4:

• In portrait mode, go to https://immersive-web.github.io/cardboard-vr-display/examples/index.html
• Enter WebVR
• While still in portrait mode, exit WebVR
• Orientation axis is off, it's like the default pose is now PI / -2 rotation on Z

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]

@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]

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]

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: