Polyfill broken in Chrome v65+
dustinkerstein opened this issue · comments
Update - See this comment for replication steps. It appears this issue isn't actually related to the WebXR flags, however, it may be caused by the general work being done for WebXR support.
I doubt this is much of a real issue as WebXR will be behind config flags for a while and obviously the Polyfill isn't meant to be used with WebXR, but I figured I'd document it anyway. The Polyfill probably just needs to detect when WebXR is enabled and avoid initialization.
Anyway, when you attempt to view any WebVR examples that contain the polyfill with WebXR or the WebXR Sensor Orientation flags enabled you will see whacky orientation values and the camera will move around wildly.
I'm not sure how WebXR being enabled would alter the WebVR experience. Only Chrome has WebXR implemented, and when both WebVR and WebXR are enabled, the first API that queries available devices should take control, and the other implementation should be disabled. If WebXR is enabled on a browser, it doesn't change the content code calling navigator.getVRDisplays.
That being said, there's a plan to add WebXR fallback support to the WebVR polyfill (such that, in the future when a browser only implements WebXR, the WebVR polyfill would map 1.1 code like navigator.getVRDisplays to the WebXR equivalence of navigator.xr.requestDevice and still result in a native experience).
Although a bit stumped how this can negatively affect current environments!
Hmm, well there's definitely something funky that happens when WebXR is enabled on a Polyfill site. Were you able to replicate the wild sensor values?
Which version of Chrome is this? Is Native WebVR enabled as well? Is it reproducible on the webvr.info samples? Happy to check it out!
Weird, I can no longer replicate this today... I'll close the ticket for now and keep an eye on it. Sorry about that.
No worries, thanks for reporting! I'll keep an eye out for it as well, new territory so there's sure to be some bugs out there :)
Ok. I know how to replicate this. On Chrome v65+ make sure all of Chrome://flags are reset to default (mainly disable the WebVR flag). Then go to https://files.panomoments.com/js/polyfill.html - On my Pixel XL and Moto Z with the above settings:
- Chrome Canary is a crazy wobbly mess
- Chrome Beta is very slow and only 1 axis is working (up/down)
- Chrome Dev doesn't load correctly -
Uncaught ReferenceError: WebVRPolyfill is not defined - Chrome Stable works as intended - except for those jitters :)
Are you able to see that?
So it seems actually this is less of a WebXR bug, and is possibly more of a general Polyfill issue. I'll go ahead and adjust the title to reflect this.
The behavior I described above seems to affect all Polyfill sites I've tested, ie. A-Frame appears to be broken.
Added a bug for Chromium - https://bugs.chromium.org/p/chromium/issues/detail?id=818290 since this is likely more of a Chrome issue.
Reproduced what you saw on Stable, Beta and Canary. The spinning out of control on Canary looks like deviceorientation events changed, the beta scenario just seems really weird. Unfortunately I do think it is a platform issue. I'll ask around and see if it's something that can be fixed and uplifted without breaking polyfilled content/A-Frame
In the meantime, I'll work on uplifting the Sensor patch in CardboardVRDisplay to the polyfill, it seems that still works at least.
Ok. It's looking like it was caused by the fix for this issue - https://bugs.chromium.org/p/chromium/issues/detail?id=796518 - Hopefully they can get it fixed before v65 ships next week.
@jsantell beyond the Chrome v65 issue (only being able to look up/down), it looks like v66 is going to release a breaking change for existing sites using deviceMotion - https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ple1o7bFqEs/jJuhTSEYCwAJ
It might be worth putting in a fix for Polyfill asap (flagged specifically for versions >66) so that anyone who downloads it now is covered for when v66 goes stable. What do you think?
I filed an issue (immersive-web/cardboard-vr-display#18) for the fix the rotationRate change, and we definitely should release a version with the fix and coordinate with the A-Frame folks on the change
Ok cool. We may also really might want to push against the fix planned for v65 as it breaks / degrades the deviceOrientation / deviceMotion sensor performance for many devices (2/3 of my test devices - Pixel XL and S6) - https://bugs.chromium.org/p/chromium/issues/detail?id=805146#c21 - I feel like a revert is the safer approach for now, but there's very little time left to make this change before v65 goes stable.
Confirmed with Reilly that the rotationRate change will be in m66, not m65, giving us some wiggle room.
Yeah, that's good. It's still going to break WebVR (Polyfilled) for the vast majority of users until site owners realize what happened, which IMO isn't good for the overall WebVR landscape. Though it seems like there might be a little more discussion going on here https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ple1o7bFqEs/jJuhTSEYCwAJ as to whether this change is actually needed. I just feel like we're a little too late in the game to be changing this even though Chrome implemented it incorrectly in the first place. But it's certainly not my decision :)
I'm on Chrome 65.0.3325.109 with a Moto Z. I'm having an issue with only one axis is working and it's very slow. Is there a quick fix available?
Oye, it looks like that fix didn't make it into the first stable M65 release. This means that both deviceOrientation (on some Android devices - tracked by #819413) and deviceMotion (used by the Polyfill) are currently broken in stable M65.
Ahh! That explains why we are swarmed today with bug reports. Looks like Chrome 65 has been distributed globally. Pretty much bug reports from all continents on Gyroscope locked. :(
I have a live demo today... I am planning to ask users to uninstall chrome updates but its a really bad solution.
@env3d You could try asking folks to install Chrome Beta / Canary, however, you're then exposed to https://bugs.chromium.org/p/chromium/issues/detail?id=819413 which is a slightly less severe bug.
Update - And per Jordan's note below, updating to M66 would require you to update your Polyfill as well, or else you'll get wild gyro behavior due to the rotationRate change.
There should be a subsequent update soon to Chrome m65 stable with the device orientation fix, unfortunately platform level and not much we can do to patch it on the polyfill side.
That being said, there's a change in m66 where Chrome will now use degrees instead of radians in the devicemotion event, adhering to standards, but requiring a polyfill update (UA sniffing unfortunately) to handle this change.
Fixed in immersive-web/cardboard-vr-display@d770e01
Tested this change on:
Pixel
- Chrome Stable 65.0.3325.109 (with/without sensor)
- Chrome Beta 65.0.3325.144
- Chrome Canary 67.0.3370.0
- Firefox on Android 58.0.2
- Samsung Internet 6.4.10.5 (Chrome 56.0.2924.87)
iPhone 10.3.3 - Safari
- Chrome 65.0.3325.152
- Edge 41.11
- Firefox v10.6
iPhone X iOS 11.2.6 - Safari
- Chrome 65.0.3325.152
--
This provides a deviceorientation fallback on Chrome m65 builds that are affected by devicemotion breaking, also the rotationRate unit change in >=m66. The low frequency of device events isn't fixed unfortunately, and maybe we can work on an interpolation/pose prediction solution, but want to get this fix out first at least.
This fix however breaks with webvr-ui ; what type of updates would be required there?
EDIT: Sorry, understood that the root cause of breakage is the change in navigation.getVRDisplays() behavior. On Chrome 65, desktop navigation.getVRDisplays is undefined. checking.
@devasur didn't see this comment here, but followed up on the webvr-ui issue: googlearchive/webvr-ui#20 (comment)