Can't see a way to edit my original post, but to clarify, Canary 64.0.3251.0 behaves the same as 62.0.3202.66 in that it dispatches the initial events and none after.

We've gone back and loaded a variety of versions of Chrome onto our devices to try to narrow down the commit range that the issue was introduced. 

- Latest available APK that both events were available in was 62.0.3193.3
- Oldest available APK that devicemotion is broken was 62.0.3199.4
- As deviceorientation appears to be fixed in Chrome 62.0.3202.73, we didn't investigate when this originally broke

https://chromium.googlesource.com/chromium/src/+log/62.0.3193.3..62.0.3199.4?&n=10000

If there is any more information we can provide, steps we can take to help resolve, or potential solutions for a workaround, we're happy to assist and appreciate help that can be offered.

Thanks!

tech@lithodomosvr.com -- Thank You for the update.
Could you please provide us a screen cast of the issue which would help us in triaging the issue further.

msrchandra@chromium.org - not sure if this is exactly what you wanted, but you can see the user agent in both videos to validate browser version for the WebView and it demonstrates the lack of devicemotion events both visually (no tracking in A-Frame sample) and also in the console (no subsequent events)

- Chrome 56.0.2924.87 (default in Android 7.0) w/ devicemotion working - https://youtu.be/CYMSe6Iq97Q
- Chrome 62.0.3202.73 (current Stable release) w/ devicemotion broken - https://youtu.be/FV8r7eSMgWk

If there's anything else we can provide or any workarounds you can suggest, love to hear.

Thanks,
LithodomosVR

Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

tech@lithodomosvr.com -- Thank You for the quick update

Tested the issue on Chrome Stable# 61.0.3163.98 / 62.0.3202.73 & Chrome Canary# 64.0.3255.2.0 on Samsung SM-J710F / Android 7.0.0 and was able to reproduce the issue using the below steps --
1. Launch Chrome and navigate to "https://aframe.io/aframe/examples/boilerplate/hello-world/"
2. Observe the behavior of image while device orientation.

This is a Non-Regression Issue existing from M55 builds.
Please find the logs and screencast in the below URL (includes screen cast of Android 7.0 & 8.0) --
go/chrome-androidlogs/779443


Note: Tested the same on Pixel XL (Android 7.1.2 / N2G48E) and could not reproduce the issue.
Thank You.

msrchandra@chromium.org - we very much appreciate your responsiveness too :)

As I can't see the logs and screencast from your link, I just wanted to respond again and to ensure our issue is clear as your response & the issues "components"property refers to device orientation which appears to be working as of 62.0.3202.73. It's device **motion** that is still buggy.

Our Pixel XL is out of the office at the moment, but we had reports from staff that the issue existed on the device. When it returns to the office, I'll test it and let you know our outcome, as I don't want to provide inaccurate or conflicting info. If this isn't necessary, let me know.

As I don't understand the Chromium project/internals, I apologize if this issue has been categorized correctly! Just want to be as helpful as possible.

Thanks.

The Blink>Sensor>DeviceOrientation component is appropriate for devicemotion event bugs because they are part of the same specification. In Chrome 62 there was a refactor of how devicemotion events are generated. Adding juncai@ for that.

I'm not observing an issue with your demo app on Chrome 64.0.3254.2. Can you clarify how your application behaves when devicemotion is buggy but deviceorientation works correctly?

I'm pretty sure I'm also experiencing this issue on a Samsung S7 with Chrome 62. 

We have a load of Cordova Apps using Three.js with the WebVR Boilerplate, all the apps are not longer rotating with device as of around a week ago.

The sensor isn't updating.

The same code runs fine in Chrome, but just not in WebView. 

Reverting to Crosswalk fixed it for now, but not a long term option.

There seems to be some confusion.

This issue applies to Chrome WebView, not the Chrome Browser.

Yes to confirm in my case WebView is the problem, the Chrome Browser works as expected. 

My Apologies for the typo error in Comment# 7.

Note: Tested the same on Pixel XL (Android 8.0.0 / N2G48E) and could not reproduce the issue.
Thank You.

@msrchandra@chromium.org
Can you confirm that you could NOT reproduce this issue on Chrome WebView 62 (as in, a WebView based app)? Or was this on Chrome Browser 62 on Android?

It is important to understand that this issue relates to Chrome WebView only.

If you need an APK that displays the issue I'm having, this one should rotate like a VR scene

Deleted: android-debug.apk 6.2 MB

android-debug.apk 6.2 MB Download

reillyg@chromium.org - we took a look at 64.0.3254.2 today, and the issue still exists. To be clear about the issue:

devicemotion events are not being dispatched using an Android WebView that is using Chromium 62.0.3199.4 onwards.

We have been able to reliably reproduce the issue on both the Galaxy S6 & S7 using Chrome for Android Stable/Beta/Dev/Canary & the Android System WebView with every APK that's hit the Play Store, ranging from version 62.0.3199.4 through 64.0.3254.2. We've tested on multiple real devices, some of which were factory reset prior to testing. We have had a report that the issue also affects the Pixel XL, but I cannot confirm 100% as the device won't be back in our office until sometime next week, but I had to personally instruct the staff member with the device on how to downgrade Chrome so that he could use it for a presentation.

Our testing has been severely thorough, as this bug is the only thing standing between us and a product launch. I will validate the status of the Pixel XL when it returns, and I'll also run trials on any other alternative devices I can gather next week. I'll also provide specific model details & Android versions. If there's anything else I can provide, please let me know.

To repeat, this issue is specific to the devicemotion event in the Android WebView, starting with 62.0.3199.4, the earliest release we can find with the issue.

It does NOT occur on the desktop version of Chrome, nor using the Chrome for Android app.

Thanks!

I will try reproducing this issue and see what causes this.

Thanks for clarifying. juncai@ is investigating. My current theory is that there is a difference in how the Device Service is initialized when WebView is started that is causing the SensorProvider interface that devicemotion events relies on to not be available.

We got our Pixel XL back in the office today and tested the issue on 62.0.3202.73 in a WebView as per our other tests. As per our original report (and conflicting with msrchandra@chromium.org's report), we experienced the same issue where `devicemotion` events are not dispatched as expected.

User agent: Mozilla/5.0 (Linux; Android 8.0.0; Pixel XL Build/OPR3.170623.008; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/62.0.3202.73 Mobile Safari/537.36"

I did some tests and the device motion event started not working on WebView after the motion refactoring CL was landed:
https://chromium-review.googlesource.com/c/chromium/src/+/618162

I will do some further investigation of how to fix it. Thanks for reporting the issue and testing on various devices!

Problem found, it is because of the sensor permission:
https://cs.chromium.org/chromium/src/content/browser/generic_sensor/sensor_provider_proxy_impl.cc?l=70-72
returns permission denied for WebView:
https://cs.chromium.org/chromium/src/android_webview/browser/aw_permission_manager.cc?l=496-508
Adding code to allow sensor permission on WebView solves the problem. I will have a CL to fix that.

Adding WebView component and targeting this for the M-63 milestone since this is a regression in M-62.

Thanks so much for tackling & resolving this issue so quickly. A lot of relief on our end!

Just to confirm, does M-63 mean it *will* ship in Chromium 63, or it will ideally ship as early as 63?

Thanks again.

M-63 is currently in beta which means that this change will land in M-64 and then this bug will be flagged for review for merging this change back to the M-63 beta branch. If that merge is approved then this will be fixed in M-63 as well. M-62 has already shipped to stable users and the bar for merging fixes into a stable release is much higher.

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

commit b6c4e590df557fce300e3178e8d4c2e6cfdd7bce
Author: Jun Cai <juncai@chromium.org>
Date: Thu Nov 09 21:01:25 2017

Grant generic sensor permission for Android WebView

This CL adds code to grant generic sensor permission for Android
WebView so that the sensors needed by device motion and orientation can
be obtained from the generic sensor provider.

Note: This will not allow Android WebView to have access to all the
sensors that the generic sensor API provides since
SensorProviderImpl::GetSensor() is still guarded by
features::kGenericSensorExtraClasses flag. There is no new sensors
permission granted, and the sensors that are exposed on WebView by
this CL are those sensors that are already available on WebView
previously which are used to implement device motion/orientation
events.

Bug:  779443 
Change-Id: I1405e54213bb07d1d781181e473fc77e89bb12ed
Reviewed-on: https://chromium-review.googlesource.com/759240
Commit-Queue: Jun Cai <juncai@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Tao Bai <michaelbai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515285}
[modify] https://crrev.com/b6c4e590df557fce300e3178e8d4c2e6cfdd7bce/android_webview/browser/aw_permission_manager.cc

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

Hi,

Not only devicemotion/orientation events is not working in WebView post-Chrome 62.
Gyroscope sensor is also not working!!!
As reported https://bugs.chromium.org/p/chromium/issues/detail?id=783557

BR
JPhD

 Issue 783557  has been merged into this issue.

Has the fix been verified in the latest canary?

I verified it on my local machine and it fixed the issue.

So, after a Samsung S7 test, regression is fixe under Chrome Canary.

Merge approved for  https://chromium-review.googlesource.com/759240 into M63 branch 3239. Please verify the fix after merging it.

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

commit 3659c346f40a9c877245809ef1958fb356b3aafd
Author: Jun Cai <juncai@chromium.org>
Date: Sat Nov 11 00:09:48 2017

Grant generic sensor permission for Android WebView

This CL adds code to grant generic sensor permission for Android
WebView so that the sensors needed by device motion and orientation can
be obtained from the generic sensor provider.

Note: This will not allow Android WebView to have access to all the
sensors that the generic sensor API provides since
SensorProviderImpl::GetSensor() is still guarded by
features::kGenericSensorExtraClasses flag. There is no new sensors
permission granted, and the sensors that are exposed on WebView by
this CL are those sensors that are already available on WebView
previously which are used to implement device motion/orientation
events.

TBR=juncai@chromium.org

(cherry picked from commit b6c4e590df557fce300e3178e8d4c2e6cfdd7bce)

Bug:  779443 
Change-Id: I1405e54213bb07d1d781181e473fc77e89bb12ed
Reviewed-on: https://chromium-review.googlesource.com/759240
Commit-Queue: Jun Cai <juncai@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Tao Bai <michaelbai@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#515285}
Reviewed-on: https://chromium-review.googlesource.com/765011
Reviewed-by: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#448}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/3659c346f40a9c877245809ef1958fb356b3aafd/android_webview/browser/aw_permission_manager.cc

The CL was merged into M63 branch 3239. I verified the M63 branch 3239 after the merge and the issue is fixed.

Thank you for being proactive in finding a solution. I also tested, and see the fix is working in Chrome Canary webview implementation.

To be clear, will this fix be in the Stable release of Chrome 63?

Are there efforts being made to patch the Stable release of Chrome 62?

Since many apps may or may not update their chrome 62 version, without a patch for chrome 62, it is unclear when the fix can be widely used.

The fix will be in the Stable release of Chrome 63.

I was able to repro the bug on pixel 2 with webview shell/browser on webview : 62.0.3202.66 for the url on comment#1 
( https://aframe.io/aframe/examples/boilerplate/hello-world/)

And with latest M63/beta verified the fix on Samsung S8/NRD90M and pixel 2/Android O devices with webview : 63.0.3239.53 (beta)

Verified/fix on pxiel 2/android O/M64/dev/webview: 64.0.3269.0 

Reopening this issue as issue reproducible on S8/NRD90M and Sony experia Z3/6.0.1 with 66.0.3343.0 

We have another bug tracking this issue in crbug/682535 mentioning the same issue . 

sbashyam@, I have closed issue 682535 as the breakage of the JsFiddle example there is expected. I've tried the demo from the description in this issue on with Chrome 66.0.3343.0 set as the system webview provider on a Pixel 2 and cannot reproduce this issue. Which specific example have you tried?

Can this issue be closed since it seems not be able to reproduce this issue according to Comment 49?

This issue has been Needs-Feedback for a month. I think it's fine to close.

Hi there - I'm experiencing problems which I think are related to this too. Moto G4 Plus running Android 7.0. Using Krpano gyro2 (uses devicemotion - see https://krpano.com/plugins/gyro2/) inside a Cordova app. I have tried it with Chrome webview (Chromium 64), Chrome Beta (65), Chrome Dev (66) and Chrome Canary (67), and with all of them the gyro either works only vertically, or does not move at all. 
I have tried it with Crosswalk webview (the final version used Chromium 50-something) and it works fine, which would suggest it's a Chromium issue rather than anything else to do with my setup.
I have also tried the Threejs deviceorientation (https://gist.github.com/kopiro/86aac4eb19ac29ae62c950ad2106a10e, https://threejs.org/examples/misc_controls_deviceorientation.html) with latest Chrome and although sluggish, it works fine. This suggests it is specific to devicemotion rather than deviceorientation, as mentioned in the comment thread above.
Thank you.

Hi richwfletcher@gmail.com, is there a website that I can do a quick test?

Hi richwfletcher@gmail.com I'm also a krpano developer and experience the issues with gyro etc.

Here's a link for an example, click the bottom left squiggle gyro icon.

http://wearereality.com/dev/clients/NYMR/1-0/?startscene=32&startactions=lookat(10.22,-0.6,107.94,0,0);

My wife's S8 on version 64.0.3282.137 works fine.

This is a major problem.

My chrome version: 65.0.3325.109

Hello - thank you for the response. Here are two basic apps to try as a
test - deviceorientation.apk uses Cordova and Threejs, employing
deviceorientation, and works fine. Devicemotion.apk uses Cordova and
Krpano's gyro2 based on devicemotion, and only the vertical axis seems to
work, whether I'm using Chrome, Dev, Beta or Canary webview.
Thank you again!

Same for me with latest Chrome 65.0.3325.109
Chrome v64 on a S6 works great.

I am wondering if the gyro doesn't work at all, or it is hyper-sensitive? If it is hyper-sensitive, it may be because of the recent change in the units of rotationRate done to bring Chrome in line with the spec and Firefox's behavior, refer to the comment at:
https://bugs.chromium.org/p/chromium/issues/detail?id=818290#c6

https://groups.google.com/a/chromium.org/d/msg/blink-dev/ple1o7bFqEs/jJuhTSEYCwAJ

With devicemotion.apk it only works vertically i.e. I can move the phone up and down and the pano will move correspondingly(although more sluggish than with previous chromium versions e.g. Crosswalk webview), but it won't move at all left or right-it's fixed facing the same direction despite rotating the Moto G4 Plus left and right. It doesn't appear to be hypersensitivity; the opposite if anything!

What version of Android WebView are you using?

If it is updating very slowly, maybe it is due to the sensor update frequency:
https://bugs.chromium.org/p/chromium/issues/detail?id=819413&desc=3

It looks like the latest WebView Dev version (66.0.3359.14) doesn't have the above fix yet, you can try the next WebView Dev version when it comes out (it should come out soon) to see if there is any change.

The webview versions I have tried are 64, Beta (65), Dev (66) and Canary (67). I can check the exact versions if that would help.

hmm..., I tested the link at Comment 56 using the latest Chrome Canary (67.0.3368.0), and although it is hyper-sensitive (I believe it is due to the units change of rotationRate), rotating phone in three axises does work. Can you test that link using the latest Chrome Canary (67.0.3368.0) to see if it works?

Not working on 65.0.3325.109 (only vertical axis)
Working with 66.x version but as you said the conversion from radians to degrees of the gyroscope rotations is not the good one ;)

Yes, I can confirm what you've reported - the link in Comment 56 only works
on the vertical axis with Chrome and Chrome Beta (65), but with Dev (66)
and Canary (67) it works on all three axes, albeit with the
hypersensitivity.
However, this isn't the behaviour in the two apks I uploaded in Comment 59;
deviceorientation.apk (uses Cordova and Threejs deviceorientationcontrols)
works on all three axes in all four Chrome versions; devicemotion.apk (uses
Cordova and Krpano gyro2 (uses devicemotion - see
https://krpano.com/plugins/gyro2/) only works on the vertical axis no
matter which of the four Chrome versions I try (I'm changing the Browser
app in the Settings). Were you able to test these out at all?
Thank you for looking into this - much appreciated!

Yes, for the link in Comment 56, my test result is the same as yours: only works on the vertical axis with Chrome and Chrome Beta (65), but with Dev (66)
and Canary (67) it works on all three axes.

But for the devicemotion apk, my test result is the same as testing the link in Comment 56. I think changing the Browser app in the Settings may not affect the WebView that native apps use. So on Android, you can try the following to select which WebView version to use for native apps: Settings -> System -> Developer options -> WebView implementation.

I believe the reason that Chrome and Chrome Beta (65) works only on the vertical axis is because Chrome M65 version that has the fix hasn't been released yet:
https://bugs.chromium.org/p/chromium/issues/detail?id=805146#c38
So I suggest to wait a couple of days and test them on the next Chrome Beta version.

Thank you very much for the advice about webview implementation - I will
try that out.
Will the Chrome M65 version aim to fix the hypersensitivity problem as
well, or just the issue about only working on the vertical axis?

The hypersensitivity issue is caused by the change in units explained here:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/ple1o7bFqEs/jJuhTSEYCwAJ

Still reproducible on Pixel / OPM1.171019.028 ,  HTC X9 / MRA 58K and Nexus 6/MOI10L having 66.0.3359.30 and 67.0.3369.0 (Issue is not fixed in ToT). Once fixed ,Please merge the fix to 66 branch as well.

Hi sbashyam@, can you add some details about the testing results?

Chrome beta 65 - only use gyro vertically and sluggish.
Chrome dev 66 - hyperdensitive but all 3 axis.
Chrome canary 67 - same as dev 66, hypersensitive but rotates on all 3 gyro
axis.

Tested on Samsung S7 Edge

On 14 Mar 2018 00:25, "jun… via monorail" <monorail+v2.4231759727@
chromium.org> wrote:

Chrome 65 uses gyro vertically but sluggish .
Good Build : 65.0.3325.59
Bad  Build : 65.0.3325.61 
However could not do per-cl on Nexus 6/MOB31V

https://chromium.googlesource.com/chromium/src/+/b29ba0d062280291845dd8a5bd9dc052e439bbb5

Chrome 66 and Chrome 67 is hypersentive and rotates on all axis.

This sunday is cloudy...

On Samsung S7 edge, 
Chrome Canary 67.0.3374.0 
Chrome Beta 66.0.3359.30
gyro are hypersentive and rotates on all axis.

Chrome Stable 65.0.3325.109
gyro ONLY vertically but sluggish .

!!!

Tested on multiple Android devices including Pixels and Galaxy S7s, etc.

Chrome stable 65.0.3325.109 deviceorientation doesn't work at all.

Chrome Beta 66.0.3359.30 & Canary 67.0.3374.0 both work but very sluggish and ugly 8(

See comment below about it really being deviceorientationabsolute that's not working - deviceorientation does seem to be working in v65 but is sluggish.

https://bugs.chromium.org/p/chromium/issues/detail?id=823189#c1

deviceorientation sensor was working fine for my game on v63 chrome but since v65.0.3325.109 release it has stopped working. This is a bummer. Please fix this asap. We are incurring huge losses because of it.

Hi,

For those who are business impacted, as me, try:
- upload the stable historic version 63-0-3239-111
- uninstall the current version (required)
- re-install the historic one
- deactivate auto upgrade for application

On S7, S7+ this is working.

On my Samsung Galaxy S6, all current versions of Chrome, Chrome Dev and Chrome Beta show incorrect gyro behavior at multiple VR/360 websites. Either the gyro response is wildly unstable & hypersensitive, or it works very slowly and only on the vertical axis. The current Samsung Internet app is usable, though both jumpy & sluggish.

Rolling back the factory installed Chrome app to the original version, which is several years old, restored correct gyro behavior. I was also able able to install version 63.0.3239.71 of Chrome Beta, which works right. So this is definitely a case of "better is the assasin of good".

I hope there is a fix real soon, as this is a major problem for the VR industry.

Only one axis working was a bug in M65, which is fixed in M66, which is currently rolling out to the stable channel.

The "hypersensitivity" is because M66 *also* changed the units in which the angle is reported to be degrees, instead of radians, to comply with the spec and match the behaviour of other browsers - this makes the numbers much larger.

You need to update your code (or the libraries your code depends on) - it's likely that the libraries in question have a special case for Chrome where they interpret it as radians, and that special case is no longer appropriate.

I'm going to close this for now, because as far as we can tell all the issues are currently resolved. It's just unfortunate and confusing that the version which fixed the actual bug that was preventing this from functioning correctly *also* changed the intentional behavior in an unrelated way.

See https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ple1o7bFqEs/jJuhTSEYCwAJ for more information about the change from radians to degrees.

If you have an app that is still experiencing an issue on M66 or later and you have verified that your code is *definitely* treating the angle as degrees, not radians, then please file a new WebView bug (this one has gotten rather long and confusing already) with a repro example that we can look into.

Simply unbelievable. I'm trying to port a simple Canvas-based game from iOS to Android, and even the most basic things represent massive roadblocks on Android. This platform is doomed.

If there is a specific compatibility issue causing you trouble please let us know. With regard to this issue the behavior of Chrome now matches that of Mobile Safari so I am unsure what roadblock you could be referring to.