To be more exact, the region can still be mapped multiple times, but only read-only once it has been "sealed". Normally, the sensor provider should have a writable mapping to the region that is created before that happens, then all other clients (readers) should map the region read-only.

I'll look into this very shortly.

For the record, here is the location where the mappings into the same buffer, but with different offsets, are created:

https://cs.chromium.org/chromium/src/services/device/generic_sensor/platform_sensor_provider_base.cc?gsn=CloneSharedBufferHandle&l=151

Confirmed that the CL above landed after the M-65 branch cut so this only effects M-66.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c0c8978849ac57e4ecd613ddc8ff7852a2054734

commit c0c8978849ac57e4ecd613ddc8ff7852a2054734
Author: David 'Digit' Turner <digit@google.com>
Date: Mon Jan 29 21:55:58 2018

android: Fix sensors in device service.

This patch fixes a bug that prevented more than one sensor data
to be available at once when using the device motion/orientation
API.

The issue was introduced by this other patch [1] which fixed
some security-related issues in the way shared memory region
handles are managed throughout Chromium (more details at
 https://crbug.com/789959 ).

The device service´s sensor implementation doesn´t work
correctly because it assumes it is possible to create a
writable mapping of a given shared memory region at any
time. This assumption is not correct on Android, once an
Ashmem region has been turned read-only, such mappings
are no longer possible.

To fix the implementation, this CL changes the following:

- PlatformSensor used to require moving a
  mojo::ScopedSharedBufferMapping into the newly-created
  instance. Said mapping being owned by and destroyed
  with the PlatformSensor instance.

  With this patch, the constructor instead takes a single
  pointer to the corresponding SensorReadingSharedBuffer,
  i.e. the area in memory where the sensor-specific
  reading data is located, and can be either updated
  or read-from.

  Note that the PlatformSensor does not own the mapping
  anymore.

- PlatformSensorProviderBase holds the *single* writable
  mapping that is used to store all SensorReadingSharedBuffer
  buffers. It is created just after the region itself,
  and thus can be used even after the region's access
  mode has been changed to read-only.

  Addresses within the mapping will be passed to
  PlatformSensor constructors, computed from the
  mapping's base address plus a sensor-specific
  offset.

  The mapping is now owned by the
  PlatformSensorProviderBase instance.

Note that, security-wise, nothing changes, because all
mojo::ScopedSharedBufferMapping before the patch actually
pointed to the same writable-page in memory anyway.

Since unit or integration tests didn't catch the regression
when [1] was submitted, this patch was tested manually by
running a newly-built Chrome apk in the Android emulator
and on a real device running Android O.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/805238

BUG= 805146 
R=mattcary@chromium.org,alexilin@chromium.org,juncai@chromium.org,reillyg@chromium.org

Change-Id: I7d60a1cad278f48c361d2ece5a90de10eb082b44
Reviewed-on: https://chromium-review.googlesource.com/891180
Commit-Queue: David Turner <digit@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Matthew Cary <mattcary@chromium.org>
Reviewed-by: Alexandr Ilin <alexilin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532607}
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/fake_platform_sensor_and_provider.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/fake_platform_sensor_and_provider.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_accelerometer_mac.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_accelerometer_mac.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_ambient_light_mac.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_ambient_light_mac.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_android.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_android.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_fusion.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_fusion.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_fusion_unittest.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_linux.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_linux.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_android.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_android.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_base.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_base.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_linux.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_linux.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_mac.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_mac.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_win.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_provider_win.h
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_win.cc
[modify] https://crrev.com/c0c8978849ac57e4ecd613ddc8ff7852a2054734/services/device/generic_sensor/platform_sensor_win.h

I verified this issue on Android with the latest Chrome Canary(66.0.3336.0).
It has been fixed.

Thanks :)

It looks like the above fix for sensor data was not merged to M-65 branch, while the CL that caused the sensor data not working properly was merged to M-65 branch.
https://chromium-review.googlesource.com/c/chromium/src/+/805238
was merged at:
https://chromium.googlesource.com/chromium/src.git/+/5826891a08d8c63947d8f41ab9c15c565f96e74e

So reopen this issue and add M-65 merge request.

 Issue 818290  has been merged into this issue.

This bug requires manual review: We are only 2 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Are there any branches that currently contain the full fix for this? I'd like to confirm that this change isn't what causes the hyper-sensitive sensor issue visible in Canary here - https://aframe.io/examples (ensure WebVR flag is set to disabled or default). 

The M-65 branch currently doesn't contain this fix. The Canary contains this fix.

Ok, then it's possible this fix is what causes the hyper-sensitive sensor issue. See this video -https://drive.google.com/open?id=1wGFSYwaNnbKp96kJ-_tueKjsPqvZS6nS - Have you seen this before?

Also, in Canary I see deviceMotion updates around 12hz on my Pixel XL. This works at 60hz in Chrome Stable. Polyfilled WebVR sites (or any site that uses deviceMotion) rely on having the fastest possible sensor updates. Is it possible to maintain the fastest sensor readout in addition to fixing the original issue this current ticket is about?

I haven't seen the jitters when testing https://aframe.io/examples.

The fix at:
https://bugs.chromium.org/p/chromium/issues/detail?id=796518
already makes sure that the maximum frequency is used. We used to use 60Hz, but as mentioned in the above link, on some devices, this
frequency is larger than the maximum frequency the device can provide. So we modified code to set the sensor frequency not exceed the maximum frequency the device supports.

What devices are you testing on? I can replicate this hyper-sensitivity on a Pixel XL, Moto Z, and Samsung Galaxy S6.

I would imagine that the Pixel XL is capable of 60hz as Chrome stable renders this animation very smoothly (at 60hz) - https://genericsensors.appspot.com - When tested in Canary, the animation is very choppy (measured at ~12fps). Is it possible that the device detection of the max frequency isn't working properly?

Sorry, I meant this link - http://googlesamples.github.io/web-fundamentals/fundamentals/native-hardware/device-orientation/dev-orientation.html

I just tested that sensor link on a few devices using Canary:

Pixel XL    12hz
Moto Z      60hz
Galaxy S6   5hz

And on Chrome Stable each device runs at 60hz.

Dustin, as explained here the hypersensitivity in Chrome 66 is expected:

https://bugs.chromium.org/p/chromium/issues/detail?id=818290#c6

I used pixel 2 to test, not pixel 2 xl.

The maximum frequency is obtained from the following code for Android devices:
https://cs.chromium.org/chromium/src/services/device/generic_sensor/android/java/src/org/chromium/device/sensors/PlatformSensor.java?l=135-138

Got it. Sorry about that. It would be nice if that could be announced somehow so that folks that have apps dependent on deviceOrientation (ie. all Polyfilled WebVR sites) can start planning workarounds. 

But back to the sensor readout speed. Those numbers for those devices aren't expected, right?

Based on the numbers I'm seeing, it seems like mMinDelayUsec is reporting 11 for the Galaxy S6 and 5 for the Pixel XL. However, I know these devices support faster sensor readouts (as confirmed by current Chrome Stable and other native applications I've tested).

I just tested a few deviceMotion / deviceOrientation demo's on the internet and they confirm the sensor readout numbers above. These devices aren't just pumping out duplicated data, ie. taking a 30hz sensor readout and doubling to 60hz. They actually do have the 60hz granularity as is clearly visible by trying these demos in Chrome Stable.


Apologies for the many messages, but my concern is that this fix being released in a few days is going to break / significantly degrade all Polyfill dependent WebVR sites (as well as any site that uses deviceMotion) for a potentially large but unknown number of devices - 2/3 of my test devices, a Pixel XL and S6. Do you see an alternative solution for 796518? Is a revert feasible at this point?

I'm worried about this landing in stable 65 -- this will break all WebVR content using the webvr-polyfill[0], which a good chunk of content uses, including all A-Frame[1], Vizor[2], Google's Poly[3] and PlayCanvas[4] for anyone experiencing that content who doesn't have a WebVR-enabled browser. Which includes all iOS devices, and all android browsers except Chrome on Daydream-enabled phones and Samsung Internet for GearVR.

The rotationRate unit change is something we can work around and land a patch in the polyfill and communicate to consumers to update before 66 rolls around, but is there anything we can do to ensure m65 users have both the working deviceorientation events and a high frequency rate? And would this fix also include the rotationRate change?

[0] https://github.com/immersive-web/webvr-polyfill
[1] https://aframe.io/
[2] https://site.vizor.io/
[3] https://poly.google.com/
[4] https://playcanvas.com/

+cmasso@ for merge approval.

The missing data issue will be resolved by merging the patch as requested in comment #7. If you patch your demos to work with the new gyroscope units (I assume they already have code for this because this is the behavior in Firefox) then you can test the end state on Chrome Dev. If there are still issues there please file a separate issue for that so we can keep the root causes straight.

I believe that the sluggishness in the demo is caused by it trying to interpolate with only one working sensor.

+cmasso@google.com because they appear not to log in with their @chromium.org account.

Look at some of the other deviceOrientation / deviceMotion examples on devices like a Pixel XL or S6 like this one - https://threejs.org/examples/?q=dev#misc_controls_deviceorientation

On those devices in Canary, I can clearly see the sensor readout at 12hz and 5hz respectively, which entirely breaks the experience. Can you replicate this with a device you have?

Thanks Reilly! To clarify, the patch landing here for m65 will fix the issues of devicemotion not working, and include the rotationRate unit change? Sounds good, we can work to get a new version of the WebVR polyfill out with this change and communicate with users ASAP.

Dustin, FWIW I made a test page for displaying the rate of devicemotion events here: https://devicemotion-rate.glitch.me/. On a Pixel and Pixel 2 (neither XL), on Stable/Beta/Canary I'm getting ~55hz. If you're seeing 12hz/5hz on this page, that sounds like a separate issue

It looks like the issue is not with deviceMotion, but with deviceOrientation. Try this link - https://curly-age.glitch.me

deviceOrientation is used much more widely, correct? 

The DeviceOrientationControls used in that three.js link has much more simple logic than the sensor fusion devicemotion event used in the Polyfill, but I think lacks acceleration needed for the sensor fusion used in the polyfill. Which one is used more, I'm unsure of, but my understanding both are going to the wayside with new Sensor APIs.

On Pixel 1 using the deviceorientation link in comment 27, m64 and m66 are around ~48hz, with beta m65 approaching 0, it looks like there's very few events if any at all.

We should probably continue this in another issue though

Ok, good to know that this doesn't directly affect the Polyfill / WebVR. However, it's likely there are many more sites using deviceOrientation compared to deviceMotion, resulting in an even bigger potential impact, no?

It's definitely this fix that changes this sensor readout behavior. The max readout rate is being governed by the logic described in Comment 18 (resulting in 12hz on Pixel 1 XL and 5hz on S6). 

The https://curly-age.glitch.me 'events per second' will only drift to zero if you're not actually moving your phone. If you keep the device moving, you will see it capped at the sensor readout speed noted above.

Please file a separate issue for the sensor event rate issue. This issue only covers the issue of only one sensor reporting data.

Ok I can do that, I'm just a little confused and concerned about the m65 release. The fix for this issue (805146) causes a regression of the deviceOrientation sensor readout speed which will have widespread effect across websites that rely on this API. While it does make sense to have the readout speed limited by what the hardware says is possible, the current method isn't returning accurate results, leading to a large degradation in the deviceOrientation performance across many hardware devices. Should this not be considered before releasing this fix in m65?

It should be considered however it is confusing this issue to discuss multiple problems all in one thread. We know how to fix the problem represented by this issue and need further investigation of the other problems.

To clarify, here are the two issues:

[1] The fix for 796518 (which apparently requires 805146) causes a regression in the sensor readout for an unknown but likely large number of devices for the deviceOrientation API.
[2] The deviceMotion rotationRate spec change tracked by https://bugs.chromium.org/p/chromium/issues/detail?id=541607 causes issues with the current Polyfill and other sites dependent on deviceMotion.

[2] is out of scope and can be handled by a Polyfill update. [1] is the main concern as m65 ships in a few days.

Sorry for the message spam.

Update some information for the M65 merge request:
The CL in Comment 4 has been landed in M66 for quite a while and we believe that it is safe to merge it to M65.

I am still not very comfortable merging this into M65 but since the number of users affected is low, and that the change is safe as per #34, I am approving the merge

We're essentially trading a bug in the deviceMotion API (#796518) which is used by only a small number of sites, for a new deviceOrientation bug which is used by a much larger number of sites. Is there any data on the number of deviceOrientation dependent sites?

I'll add a Chromium issue to track this new deviceOrientation regression.

dustin.kerstein@, I have not seen any evidence that these shared memory changes are the cause of sensor update frequency issues you've seen. Please CC me on the issue you file.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f99b7ddd798842c586440fa116a988ab73fc45f4

commit f99b7ddd798842c586440fa116a988ab73fc45f4
Author: David 'Digit' Turner <digit@google.com>
Date: Tue Mar 06 18:05:58 2018

android: Fix sensors in device service.

This patch fixes a bug that prevented more than one sensor data
to be available at once when using the device motion/orientation
API.

The issue was introduced by this other patch [1] which fixed
some security-related issues in the way shared memory region
handles are managed throughout Chromium (more details at
 https://crbug.com/789959 ).

The device service´s sensor implementation doesn´t work
correctly because it assumes it is possible to create a
writable mapping of a given shared memory region at any
time. This assumption is not correct on Android, once an
Ashmem region has been turned read-only, such mappings
are no longer possible.

To fix the implementation, this CL changes the following:

- PlatformSensor used to require moving a
  mojo::ScopedSharedBufferMapping into the newly-created
  instance. Said mapping being owned by and destroyed
  with the PlatformSensor instance.

  With this patch, the constructor instead takes a single
  pointer to the corresponding SensorReadingSharedBuffer,
  i.e. the area in memory where the sensor-specific
  reading data is located, and can be either updated
  or read-from.

  Note that the PlatformSensor does not own the mapping
  anymore.

- PlatformSensorProviderBase holds the *single* writable
  mapping that is used to store all SensorReadingSharedBuffer
  buffers. It is created just after the region itself,
  and thus can be used even after the region's access
  mode has been changed to read-only.

  Addresses within the mapping will be passed to
  PlatformSensor constructors, computed from the
  mapping's base address plus a sensor-specific
  offset.

  The mapping is now owned by the
  PlatformSensorProviderBase instance.

Note that, security-wise, nothing changes, because all
mojo::ScopedSharedBufferMapping before the patch actually
pointed to the same writable-page in memory anyway.

Since unit or integration tests didn't catch the regression
when [1] was submitted, this patch was tested manually by
running a newly-built Chrome apk in the Android emulator
and on a real device running Android O.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/805238

BUG= 805146 
R=​mattcary@chromium.org,alexilin@chromium.org,juncai@chromium.org,reillyg@chromium.org

Change-Id: I7d60a1cad278f48c361d2ece5a90de10eb082b44
Reviewed-on: https://chromium-review.googlesource.com/891180
Commit-Queue: David Turner <digit@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Matthew Cary <mattcary@chromium.org>
Reviewed-by: Alexandr Ilin <alexilin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#532607}(cherry picked from commit c0c8978849ac57e4ecd613ddc8ff7852a2054734)
Reviewed-on: https://chromium-review.googlesource.com/951663
Reviewed-by: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#671}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/fake_platform_sensor_and_provider.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/fake_platform_sensor_and_provider.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_accelerometer_mac.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_accelerometer_mac.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_ambient_light_mac.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_ambient_light_mac.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_android.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_android.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_fusion.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_fusion.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_fusion_unittest.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_linux.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_linux.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_android.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_android.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_base.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_base.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_linux.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_linux.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_mac.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_mac.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_win.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_provider_win.h
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_win.cc
[modify] https://crrev.com/f99b7ddd798842c586440fa116a988ab73fc45f4/services/device/generic_sensor/platform_sensor_win.h

The sensor frequency update issue is caused by 796518, but we didn't understand that until about halfway through the conversation above since 805146 was needed in M65 to complete the fix for 796518. And before merging 805146 into M65, this sensor update frequency issue was masked by another bug. 

I apologize for the confusion. Should I move this conversation to 796518? I guess what I'm really proposing is to revert 796518 rather than making any changes to 805146.

Yes, let's move the conversation about whether we are polling sensors at the right frequency back to 796518.

 Issue 819833  has been merged into this issue.

Are we sure this was merged into M65? On testing the official stable build 65.0.3325.144 on Android I see the issue where only up/down works on https://aframe.io - Can someone please investigate? This means that both deviceOrientation (on some Android devices - tracked by #819413) and deviceMotion may be broken in stable M65.

Sorry, I mean stable Chrome version 65.0.3325.109. The above version number is the current beta build (though it's still broken there as well).

I just checked M65 beta 65.0.3325.144 build, and M65 release 65.0.3325.109 build, and they don't have the fix yet. That build was released on March 6, and as Comment 38 shows, the fix was merged to M65 on the same day. So the next release will have the fix.

Ok. Do you have any idea on when the next stable m65 update will go out? This means that all of the Polyfilled WebVR sites are currently broken in M65.

Not sure the exact day, but very soon.

 Issue 820926  has been merged into this issue.

 Issue 820943  has been merged into this issue.

> Not sure the exact day, but very soon.

Is there any news on when we can expect the new M65 release with the fix?

This is a real mission-critical issue for us. We are running VR sites for major companies which are now completely useless since the gyroscope and therefore VR mode of viewing is not working. Every Polyfilled WebVR site currently being broken in M65 must put an urge on the release, no?

I can confirm the problem is solved in Chrome beta 66.0.3359.30 build, but still exists in 65.0.3325.144 build and 65.0.3325.109 build (=current release).

In Beta 66.0.3359.30 on Android 5 (Lenovo TB3-710F) and Android 6 (Point of View) only accelerationIncludingGravity is working.

goynov@, the fix for this issue has been available since 66.0.3359.4 which means you are probably running into something else with similar symptoms. Can you please open a new issue with a screenshot of http://code.viget.com/device-motion-demo/?

Hi joel.vandenhoven@artfabrik.at, sorry about the situation, we are working on evaluating whether it is necessary to release a new version of M65 to all users.

 Issue 823189  has been merged into this issue.

We have an ad technology that is used world wide. All of our clients (major global brands, millions of impressions daily) are broken on android chrome. We are telling our clients to avoid delivery of their ads on the android platform due to this issue. 

The deviceorientation and devicemotion events are not something regaled to just a group of testing developers. They have a huge commercial use, as our technology relies heavily on them. This issue has a huge detrimental effect on revenue for many of us. 

Just imagine the market share of android chrome world wide of 51%. Now remove that same percentage from our revenue. This should not be up for discussion. It should have been tested and monitored more carefully before a bug of this magnitude is released, and once found it should be an immediate hot fix. We are going on days of money lost, while you are still debating if the push is worthwhile. Please consider the business impact you have when deliberating on this decision.

Is there a set date on when this update will be live? We are losing money each day this update stays on hold. I thank you in advance for your diligence.

Estimated stable release dates are posted here: https://www.chromium.org/developers/calendar

This bug impacts our revenue too in a big way. Our company depends on Chrome and Webview being able to run our WebVR experiences. If WebVR support on Chrome is so unstable we will need to take a hard look at our business model.

I agree with joel.vandenhoven@artfabrik.at this impacts all WebVR sites and deserves a new M65 release.

Please guys, pull us out of this one!

 Issue 825287  has been merged into this issue.

Ya please fix this issue ASAP.

 Issue 825773  has been merged into this issue.

We are also VERY interested in a hot fix ASAP. Thank you.

Our organization is also extremely eager to see this issue resolved in the chrome 65 release. The issue has been resolved in chrome 66 and since then a new build of chrome 65 has been released. Is there a reason the issue was not addressed in the last build of chrome 65? Or why can't a new build be released with this fix? 

There has been no new Android build of Chrome 65 since this issue was fixed.

Perhaps I am mistaken about a chrome 65 build since the patch in chrome 66. Thank you for the reply. However what is the status for a patch for chrome 65? And how can we help make sure the sensor spec stays operational? Adtile has a entire functional testing suite for maintaining high quality sensor readings.

The best way to help us avoid regressions is to run your testing against the Chrome Dev or Beta channels, both of which are available in the Google Play Store. Once a bug has been released to stable it is often too late to fix it. We have our own testing but it can't catch everything (though it has been updated to catch this, hindsight is 20/20).

 Issue 821552  has been merged into this issue.

This is becoming a major issue with the WebVR functionality. I am sure there millions of users who own VR headsets for their mobile device who cannot utilize VR within the chromium browser. Can't you roll back to a known good revision that was fully functional?

I m in a small startup. We're working on a WebVR project for month and now we're stuck to put on the market our product because of this big issue. 
Does anyone have a good workaround ? :(

FYI, Chrome 66 for Android has started rolling out to stable channel users.

 Issue 834641  has been merged into this issue.