Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Polyfill broken in Chrome v65+ #307

Closed
dustinkerstein opened this issue Feb 22, 2018 · 26 comments

Comments

Projects
None yet
4 participants
@dustinkerstein
Copy link

commented Feb 22, 2018

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.

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

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!

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

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?

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

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!

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

Weird, I can no longer replicate this today... I'll close the ticket for now and keep an eye on it. Sorry about that.

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

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 :)

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

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.

@dustinkerstein dustinkerstein reopened this Mar 2, 2018

@dustinkerstein dustinkerstein changed the title Disable Polyfill when WebXR is enabled Polyfill issues with development branches of Chrome Mar 2, 2018

@dustinkerstein dustinkerstein changed the title Polyfill issues with development branches of Chrome Polyfill issues with Chrome v65+ Mar 2, 2018

@dustinkerstein dustinkerstein changed the title Polyfill issues with Chrome v65+ Polyfill broken in Chrome v65+ Mar 2, 2018

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

The behavior I described above seems to affect all Polyfill sites I've tested, ie. A-Frame appears to be broken.

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

Added a bug for Chromium - https://bugs.chromium.org/p/chromium/issues/detail?id=818290 since this is likely more of a Chrome issue.

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Mar 2, 2018

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

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Mar 2, 2018

In the meantime, I'll work on uplifting the Sensor patch in CardboardVRDisplay to the polyfill, it seems that still works at least.

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

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.

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 3, 2018

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

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Mar 3, 2018

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

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 3, 2018

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.

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Mar 5, 2018

Confirmed with Reilly that the rotationRate change will be in m66, not m65, giving us some wiggle room.

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 5, 2018

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 :)

@env3d

This comment has been minimized.

Copy link

commented Mar 7, 2018

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?

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 7, 2018

That should be fixed by the time m65 goes stable on Android. They merged 805146 into m65 only yesterday. That should fix the issue you describe, but unfortunately 796518 in m65 is going to break deviceOrientation for some devices. This regression is now being tracked in 819413.

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 9, 2018

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.

@devasur

This comment has been minimized.

Copy link

commented Mar 12, 2018

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. :(

@env3d

This comment has been minimized.

Copy link

commented Mar 12, 2018

I have a live demo today... I am planning to ask users to uninstall chrome updates but its a really bad solution.

@dustinkerstein

This comment has been minimized.

Copy link
Author

commented Mar 12, 2018

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

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Mar 12, 2018

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.

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Mar 14, 2018

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.

@devasur

This comment has been minimized.

Copy link

commented Mar 15, 2018

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.

@jsantell

This comment has been minimized.

Copy link
Collaborator

commented Mar 16, 2018

@devasur didn't see this comment here, but followed up on the webvr-ui issue: googlearchive/webvr-ui#20 (comment)

wan-hellopupil pushed a commit to wan-hellopupil/webvr-polyfill that referenced this issue Apr 19, 2018

Add a special case of using deviceorientation rather than devicemotio…
…n and sensor fusion on Chrome m65 builds that features devicemotion event regressions. immersive-web#307
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.