New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 818290 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 805146
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression
Proj-XR



Sign in to add a comment

deviceMotion broken in Chrome v65+

Reported by dustin.k...@gmail.com, Mar 2 2018

Issue description

Steps to reproduce the problem:
On Chrome v65+ 

1. Ensure sure all Chrome://flags are reset to default (mainly disable the WebVR flag). 
2. Go to https://files.panomoments.com/js/polyfill.html or use the attached Debug.html file
3. Note behavior

On my Pixel XL and Moto Z with the above settings:

- 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 Canary is a crazy wobbly mess
- Chrome Stable works as intended except for known jitters, see her e- https://github.com/immersive-web/webvr-polyfill/issues/168 

I originally documented this here - https://github.com/immersive-web/webvr-polyfill/issues/307#issuecomment-370039907 - when I thought it was more of a Polyfill issue + WebXR, but it seems to be much broader and will break all existing sites that depend on the Polyfill (ie. A-Frame) when Beta goes stable next week.

What is the expected behavior?
Correct sensor data.

What went wrong?
Not sure. Maybe the WebXR work.

Did this work before? Yes 64.0.3282.186

Does this work in other browsers? N/A

Chrome version: 65.0.3325.106  Channel: beta
OS Version: 7 and 8
Flash Version:
 
Debug.html
3.0 KB View Download
Components: Blink>WebVR

Comment 2 Deleted

Comment 3 Deleted

Cc: offenwanger@chromium.org jsant...@google.com
Labels: FoundIn-65
Components: Blink>Sensor
Labels: Proj-VR
Do you see similar behavior in the demos mentioned in issue 774129?
Instead of saying "Chrome Dev" please use specific version numbers because the version currently being pushed for dev-channel changes very frequently.

I can reproduce the wobbliness you saw on your Canary version with Chrome Dev 66.0.3356.0. This is likely due to a change in the units of rotationRate done to bring Chrome in line with the spec and Firefox's behavior:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/ple1o7bFqEs/jJuhTSEYCwAJ
While the appspot link in issue 774129 reports the values of the sensors, the demos[0] here apply values to a 3D model for quicker testing using the Sensor API.

With the relevant flags on, both Chrome Beta (65.0.3325.109) and Chrome Canary (66.0.3359.0) worked as expected on Intel's sensor demo.

I was able to reproduce OP's issues on the same Beta and Canary builds.

@reillyg the change of rotationRate unit makes sense and similar to other platforms when this unit is not handled correctly. No ideas on the issue on Chrome Beta, however.

[0] https://intel.github.io/generic-sensor-demos/
Yes. In quick testing of Chrome Beta I see the same issue with the axes, but also the frequency of samples is much slower:

v65 ~12hz
v64 60hz 

Verified by Rendering FPS F12 dev tools.
I'm getting the following console warning from webvr-polyfill.js on Chrome Beta 65.0.3325.109:

"Invalid timestamps detected. Time step between successive gyroscope sensor samples is very small or not monotonic"

I wonder if this is a Spectre/Meltdown mitigation issue from messing with timer accuracy.
Those timestamp warnings are quite common and removed in later versions as events were almost always received out of order at least a few times (depending on browser) FWIW

Comment 11 Deleted

Cc: juncai@chromium.org
This may be related to  issue 796518  which is marked as fixed but I can still reproduce on my Pixel 2.

+juncai FYI.
Mergedinto: 805146
Status: Duplicate (was: Unconfirmed)
We can confirm this same problem with Pixel, Pixel 2 and Nexus 5x. Pixel 2 is the most noticeable. The problem completely disappears in canary. 
Components: Blink>WebXR

Sign in to add a comment