kenneth.hislop@ -- Thanks for reporting this issue. Could you please share the application details used by you or share any sample test application where the issue is reproduced along with the device details. So that we can reproduce at our end and triage the issue accordingly.

Screen cast of the issue would help us in better understanding.

Thanks in advance!

1. Obtain the WebView Test app from the Google Playstore found at (https://play.google.com/store/apps/details?id=com.snc.test.webview2)

2. Set WebView developer settings to Chrome Canary

3. Use WebView Test to navigate to https://kenny-hislop.github.io/

Notice that the device rotation rates are all null in Canary.  

Deleted: jsfiddle.html 506 bytes

jsfiddle.html 506 bytes View Download

Deleted: Beta.png 68.1 KB

	Beta.png 68.1 KB View Download

Deleted: Canary.png 45.3 KB

	Canary.png 45.3 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Confirmed. This works in Chrome stable (67.0.3396.87) and canary (69.0.3457.0). It works in the WebView shell with Chrome stable as the provider, but not with Chrome canary as the provider.

Test team, can we please get a bisect?

Tested the issue in Android and able to reproduce the issue. 

Pre-requisite - Set the WebView to Canary from device settings.
Steps Followed:
1. Install the application from  - https://play.google.com/store/apps/details?id=com.snc.test.webview2
2. From hamburger menu, tap on "WebView".
3. Provide the URL - https://kenny-hislop.github.io/
3. Observed that all the values(device rotation rates) are displayed as "null".

Chrome versions tested:
67.0.3396.87(Stable), 69.0.3457.4(Canary)

OS:
Android 8.1.0

Android Devices:
Pixel 2 XL

Using the per-revision bisect providing the bisect results,
Good Build - 69.0.3447.0
Bad Build - 69.0.3448.0

You are looking for a change made after 563629(GOOD), but before 563630(BAD).

CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+/94c082d42d63ce1e43c126057c627dfedf2990bd

@alexander.shalamov:  Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to owner concerned.

Also, cc'ing the reviewers of the above CL.

Please navigate to below link for log's and video--
go/chrome-androidlogs/852543

Note: If the URL - https://kenny-hislop.github.io/ is accessed in Canary browser issue is not reproduced.

Thanks!

Raphael, can you take a look?

raphael@ I quickly checked and it looks like that for webview, permission is not granted by permission manager https://cs.chromium.org/chromium/src/content/browser/generic_sensor/sensor_provider_proxy_impl.cc?sq=package:chromium&g=0&l=82

reilly@ Is there webview specific configuration that is required to grant permission based on content settings?

FWIW, other APIs such as notifications, geolocation and the rest of the sensor ones also fail silently with the WebView Test app.

I know that notifications aren't supported by the WebView, but geolocation should be, and there's code to handle geolocation permission requests AFAICS. I wonder if one needs to add some similar plumbing code for sensors?

Answering some of my own questions, according to https://cs.chromium.org/chromium/src/android_webview/browser/aw_permission_manager.cc?q=aw_permission_manager.cc&sq=package:chromium&dr&l=325 the webview is just denying all sensor-related permission requests.

raphael@ yes, that is the root cause. I think we forgot to handle request permission path, and GetPermissionStatus always returns granted which is incorrect.

This was incorrectly implemented in https://chromium-review.googlesource.com/759240 it looks like, which added it to GetPermissionStatus but not RequestPermission. Adding author/reviewers.

I think it was correctly implemented at the time when
https://chromium-review.googlesource.com/759240
was landed because at that time, the sensor request permission code was not there yet, and it wouldn't request permission for sensors from WebView. So the above CL was needed to fix Android WebView device motion/orientation issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=779443

Now that the sensor permission request is there, we need to update code to handle that.

juncai@ is there a way to get status from content settings, instead of just granting it? Or better check whether it is granted for requesting origin.

Not sure if there is an obvious way to do that, otherwise the geolocation permission on Android WebView could be implemented in a similar way since it is also in the content settings.
https://cs.chromium.org/chromium/src/android_webview/browser/aw_permission_manager.cc?l=302-306

WebView does not have content settings. It delegates permissions to the embedding application, and there is no Android API for requesting sensor permissions at present. So, the only choices are always allowed or always denied.

I think it is ok to set it always allowed because the SensorProviderImpl::GetSensor() is still guarded by:
https://cs.chromium.org/chromium/src/services/device/generic_sensor/sensor_provider_impl.cc?l=60-65
There is no new sensors permission granted, and the sensors that are exposed on WebView are those sensors that are already available on WebView
previously which are used to implement device motion/orientation
events:
https://cs.chromium.org/chromium/src/services/device/generic_sensor/sensor_provider_impl.cc?l=24-30

reillyg@, what do you think?

juncai@ based on comment from torne@ simplest option is to fix RequestPermissions, so that it is in sync with GetPermissionStatus. What do you think?

Sounds good to me.

right, we should expose this through permission API, and let WebView apps to decide whether it is allowed or not.

If we already granted this in previous versions, and Chrome grants this by default to all sites without any UI for it (which is what the original CL said) then I don't think there's a need to query the app about this. If we add an app permission callback for this, it will only take effect in a future Android version, and we will have to default deny it for all existing apps/OS versions for consistency, which will break any site relying on it for years to come :(

agreed, if chrome grants it by default, WebView shall follow it.

On the other hand, WebView probably shall provide a API to let apps deny the permission that is granted by default in next Android version.

If we redesign the permission API that may be possible, but right now there's no way to do that that's really consistent with how other permissions work.

I think WebView should hard-code the permission to "allow" for now but we need to think about adding a WebView API for it at some point if we want to require a permission for additional sensor classes.

It is regression in M69, so moving to P1. It has already bisect range #6, so removing 'Need-bisect' label.

For the record, I uploaded a CL a few hours ago: https://chromium-review.googlesource.com/c/chromium/src/+/1104417

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

commit 4429dfc0c28654be26b2e2f3190b482bfae5c58e
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Mon Jun 18 18:01:01 2018

WebView: Grant sensor permission requests

Commit b6c4e590d ("Grant generic sensor permission for Android WebView")
started always granting sensors permission requests in
GetPermissionStatus().

However, commit 94c082d42 ("[sensors] Add sensors usage indicator") caused
SensorProviderProxyImpl to query PermissionManager via RequestPermission()
before making a given sensor available.

The Android WebView case was overlooked, and its RequestPermission()
implementation was still denying all requests for sensors. Update the policy
to always-grant, and while at it make CancelPermissionRequest() not show a
"not implemented" error for sensor requests, as the requests are always
granted anyway.

Doing so re-allows the WebView to provide device motion/orientation data to
users, while SensorProviderImpl::GetSensor() still prevents other types of
sensors from being accessed, just like before.

Bug:  852543 
Change-Id: I3bd45f955f8ff9dca67b7b9bda940590dce258f1
Reviewed-on: https://chromium-review.googlesource.com/1104417
Reviewed-by: Tao Bai <michaelbai@chromium.org>
Reviewed-by: Jun Cai <juncai@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#568068}
[modify] https://crrev.com/4429dfc0c28654be26b2e2f3190b482bfae5c58e/android_webview/browser/aw_permission_manager.cc

I'm trying to verify this issue on M69/ 69.0.3474.2 on Pixel Xl/P, Trying to follow steps Comment#6  the app crashes at step#2 on "WebView Test" app




-------- beginning of crash
06-27 16:34:55.606 17879 17879 E AndroidRuntime: FATAL EXCEPTION: main
06-27 16:34:55.606 17879 17879 E AndroidRuntime: Process: com.snc.test.webview2, PID: 17879
06-27 16:34:55.606 17879 17879 E AndroidRuntime: android.util.AndroidRuntimeException: java.lang.ClassNotFoundException: com.android.webview.chromium.WebViewChromiumFactoryProviderForP
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.webkit.WebViewFactory.getProviderClass(WebViewFactory.java:465)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.webkit.WebViewFactory.getProvider(WebViewFactory.java:251)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.webkit.CookieManager.getInstance(CookieManager.java:40)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at kh.a(CSCookieManager.java:45)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at com.snc.test.webview.fragment.WebViewFragment.onResume(WebViewFragment.java:5178)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.Fragment.performResume(Fragment.java:2390)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1474)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1759)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1827)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.BackStackRecord.executeOps(BackStackRecord.java:797)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl.executeOps(FragmentManager.java:2596)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2383)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2338)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2245)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:703)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.os.Handler.handleCallback(Handler.java:873)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:99)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:193)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:6669)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: Caused by: java.lang.ClassNotFoundException: com.android.webview.chromium.WebViewChromiumFactoryProviderForP
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at java.lang.Class.classForName(Native Method)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at java.lang.Class.forName(Class.java:453)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.webkit.WebViewFactory.getWebViewProviderClass(WebViewFactory.java:176)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	at android.webkit.WebViewFactory.getProviderClass(WebViewFactory.java:459)
06-27 16:34:55.606 17879 17879 E AndroidRuntime: 	... 21 more
06-27 16:34:55.606 17879 17879 E AndroidRuntime: Caused by: java.lang.ClassNotFoundException: Didn't find class "com.android.webview.chromium.WebViewChromiumFactoryProviderForP" on path: DexPathList[[zip file "/data/app/com.android.chrome-AvBpDjVHTmkAxu92zANEZg==/base.apk"],nativeLibraryDirectories=[/data/app/com.android.chrome-AvBpDjVHTmkAxu92zANEZg==/lib/arm64, /data/app/com

the fix is here https://chromium-review.googlesource.com/c/chromium/src/+/1117652

Fix issue verified on latest M69: 69.0.3475.0 steps as per #3 and #6.

Tested device :Nexus 6P / OPM1.171019.011

Thanks!