Uncaught TypeError: e.xr.getEnvironmentBlendMode is not a function (three r152)

[vincentfretin]

Description:

I got this error in aframe inspector master that uses aframe master build

Uncaught TypeError: e.xr.getEnvironmentBlendMode is not a function

and the scene stays black.

This is probably related to three r152 update.

• A-Frame Version: master on three r152
• Platform / Device: Chrome desktop
• Reproducible Code Snippet or URL: https://aframe.io/aframe-inspector/examples/

[dmarcos]

Thanks. PRs welcome

[vincentfretin]

Of course. I usually would have done a PR directly instead of creating issues. I didn't update my project to r152 yet, I'm still on three r147. If anyone want to look at it, please go ahead, otherwise I'll look into it in a few weeks when I'll update my project to r152.

[dmarcos]

No worries. I just mention PRs welcome just for people looking for ways to contribute

[mrxz]

Three.js extended the interface of the WebXRManager with a getEnvironmentBlendMode method to query the environmentBlendMode of the underlying XRSession. A-Frame's WebVRManager doesn't have this method, resulting in this issue in case the browser doesn't support the WebXR API.

I created a PR for super-three (https://github.com/supermedium/three.js/pull/11) that simply adds a dummy implementation (similar to how it was done for getFoveation/setFoveation). Perhaps it's worth considering dropping WebVR support altogether at some point?

[dmarcos]

thanks. I think the webvr code path should only run if there’s a webvr implementation?

[mrxz]

thanks. I think the webvr code path should only run if there’s a webvr implementation?

Not quite, the decision between WebXRManager and WebVRManager is made based on the presence of the WebXR API. If that isn't present, the WebVRManager is always picked. Normally this isn't an issue as without an actual WebVR implementation, it doesn't really do anything. But the recent changes in Three.js now unconditionally call into it (renderer.xr.getEnvironmentBlendMode()).

[vincentfretin]

Ah I got the error initially when running aframe-inspector locally with npm start because it doesn't use https. I don't have the error in https.

[dmarcos]

can you elaborate? in what scenario we’re trying to invoke that function if we’re not in immersive mode?

[mrxz]

can you elaborate? in what scenario we’re trying to invoke that function if we’re not in immersive mode?

Three.js always invokes this function, regardless of immersive mode (see: https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLBackground.js#L48). So it isn't really something we're invoking ourselves. The implementation handles the absence/presence of a session.

[Matsxmats]

I have the error in Safari even when using https. Both mobile and desktop, and it just gives me a white screen.

[mrxz]

@Matsxmats Safari doesn't support WebXR (yet), so that explains why you're seeing the error even when using https. A fix (https://github.com/supermedium/three.js/pull/11) has been merged in super-three, but this hasn't landed in aframe master yet. If you're feeling adventurous you can compile your own copy with the fix included, or stick with an older version for the time being.

[Dirk-27]

@Matsxmats : you can try the patched aframe-v1.4.2_ad40be-p1.min.js from https://worried-remarkable-modem.glitch.me (see #5306). For mobile devices, you need to pick up the device and search for the scene content, as the device orientation is taken into account.

[mrxz]

This can be closed as aframe master now uses a super-three version including the fix from https://github.com/supermedium/three.js/pull/11

[dmarcos]

Fixed by https://github.com/aframevr/aframe/commit/d74c46ffe0a81171a5a014dceba3e681affcd3d0