PROVIDE_MOBILE_VRDISPLAY = true may cause native getVRDisplays to fail on mobiles

Line 39 in 124f711

if (!this.hasNative || this.config.PROVIDE_MOBILE_VRDISPLAY && isMobile()) {

Here is the situation: Oculus Go/Samsung GearVR, Oculus Browser. A-FRAME, that uses webvr-polyfill. A-FRAME intermittently fails to enter VR with the 0.10.x webvr-polyfill. We have another customer who reported the similar issue with webr-polyfill.

The option PROVIDE_MOBILE_VRDISPLAY is set to true, isMobile() returns true, the hasNative set to true also. However, the latter fact doesn't really matter, because it still goes and enables the polyfill (this.enable() call).
When PROVIDE_MOBILE_VRDISPLAY = true && isMobile() == true, the getVRDisplays runs native getVRDisplays along with setTimeout (1000) in attempt to detect that native getVRDisplays is broken (according to a comment in config.js, some old versions of Chrome had an issue when getVRDisplays didn't return any promise, like M58-M60(?)). If timeout expires first then polyfilled version will be used (which apparently is super bad for devices like Oculus Go). The timeout is set to 1 second and this timeout can easily expire even with fully functioning WebVR. When the getVRDisplays is called for the first time then Browser starts to initialize the WebVR-related code, create structures, establish IPC connections between processes: it is a whole lot of protocol that must be executed to establish WebVR. Depending on device performance and on amount of work the Browser gonna do when the page begins to load, this timeout expiration is not something extraordinary. Thus, we are getting very unstable experience when in some cases everything works and when sometimes it doesn't. Needless to say that Oculus Browser doesn't even need to use webvr-polyfill, but unfortunately, AFRAME and other frameworks/apps are relying on it.

There are several workarounds possible:

exclude Oculus Browser ("OculusBrowser" substring in user agent) from 'isMobile()'; however, will need to check if this wouldn't cause any undesired side effects;
disable PROVIDE_MOBILE_VRDISPLAY by default and enable it only when it is really necessary;
check for the browser version and initiate that timeout logic only for known bad browsers;
increase timeout to something like 3 seconds (still, if I am using debugging even this timeout can easily expire).

We can safely remove that timeout logic, you're correct it was for Chrome m58ish or something, which is pretty out of date at this point. I'll dig more into this later, but would removing that timeout fix this?

Yes, it will!