Random behaviour when trying to auto enter VR on Oculus Go

[fernandojsg]

Hardware

Oculus Go

Steps to Reproduce

1. Visit https://mixedreality.mozilla.org/webgfx-tests/examples/tests/threejs/webvr_cubes.html
   with --ez dom.vr.require-gesture false option.

Current Behavior

It automatically enter in immersive mode but sometimes it just show a solid color on the background without any geometry being rendered at all.

Expected Behavior

If you enter VR manually it should render the cubes and the wireframe background as in 2D mode.
You can try it on firefox desktop (with dom.vr.require-gesture set to false)

Additional info

• If I add a timeout of around >2000ms it works as expected 100% of the cases, if I use ~1000ms it works correctly just sometimes:

setTimeout(() => {
      scene.background = new THREE.Color( 0xff0000 );
      navigator.getVRDisplays().then(displays => {
        device = displays[0];
        //if (device.isPresenting) device.exitPresent();
        device.requestPresent( [ { source: renderer.domElement } ] );
      })
    }, 0);

• As suggested by @MortimerGoro changing this line to return false seems to make it work 100% of the times even without timeout:

  FirefoxReality/app/src/common/shared/org/mozilla/vrbrowser/browser/SettingsStore.java

  Line 331 in 2aa5299

  return true;

[MortimerGoro]

I also was able to reproduce the problem with the return false

[MortimerGoro]

I tried different approaches:

• Move calling loadUri to onResume
• Wait for the first render on the Gecko session surface
• Do not pause the compositor when VR session starts

But didn't fix the issue. FxR VR session debug lines seemed ok during the black/solid color issues, WebVR in a presenting state and receiving textures from GV pool correctly for each frame.

I wonder if it is a Gecko bug similar to this one we fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=1492554

[MortimerGoro]

It seems to work better after the latest GV version. I edited one of the WebVR samples to automatically enter WebVR (test.html.zip) and it worked for me 100% of the times when starting the application from scratch with the URL as the default one.

However, it doesn't work the first time if you exit the APP and reopen it instead of killing it. In that case we are using GV session recovery, cc @bluemarvin is the main JS run again when recovering a session or it loads a cached state? It works correctly when reloading but not the first time after a recovery.

@philip-lamb I don't think this is a blocking task for v1.1.4. It's only used for perf benchmarks and the tools always kill the app before launching each demo. Real users can never trigger this path for security reasons

[philip-lamb]

Thanks @MortimerGoro. We can wait for @bluemarvin to comment on the GV session-recovery aspect (and edit the bug description if that is indeed an issue) but I'm happy to defer this for now.