Also an issue in 58.0.3029.33

Tima, do you know if we handle chromebooks specially in WebView?

clhols@ we do not specifically support trackpad scrolling on chromebooks.

Can you please provide a compiled apk? For what it's worth, I tested WebView shell browser (a simple webview app) on a Nexus 5x with a mouse and had no issues scrolling.

Trackpad scrolling works fine on the production version.

I have attached an APK of the attached example project.

Deleted: app-debug.apk 1.6 MB

app-debug.apk 1.6 MB Download

Thank you for providing more feedback. Adding requester "ntfschr@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

Thanks for the apk!

I just tried: Nexus 5X / Android 6.0 / m58.0.3029.33 / your provided test app. No issues scrolling with a USB mouse.

What do you mean it "works fine on the production version?" Production version of your app, or production version of WebView?

Production version of the WebView. If I uninstall the beta, everything works fine again. So it's a regression in the beta.

Thank you for providing more feedback. Adding requester "ntfschr@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

I still can't repro on Nexus 5x. This sounds like it's ARC-specific.

Adding the arc component, because this seems arc-specific.

Also an issue on the Acer Chromebook 14 running Android 7.1.1 and Android System WebView version 58.0.3029.42.

Ping denniskempin@, is this Chrome OS-specific? Android has no issue scrolling.

Ping denniskempin@, is this an ARC bug?

We are seeing multiple reports on CBC concerning scrolling problems with Android apps on Chromebooks.

#CBC-RS/TC-watchlist

ntfschr: Touchpads scrolling looks very different from mouse scrolling, unfortunately it's hard to test touchpad scrolling on standard Android devices since I am not aware of any supported external touchpads for Android (Those that do work emulate a mouse).

Touchpad scrolling basically looks the same as scrolling via the touchscreen, using MotionEvents with single moving pointer.

A lot of things have changed in terms of input for the NYC build of ARC++, I will check to see if this is still an issue there.

Jim: Scrolling problems will be very specific to each app, depending on which version of Android they are targeting and how they are handling touch events. This bug here is specific for the Android WebView. 

Could point me to those reports so I can have a look? I can't guarantee that we will be able to fix the issues since the problem is primarily that most apps were never developed to be used with a mouse or touchpad. But we can do our best to make things work. 

Dennis, here are a few that seem scroll-related-
https://productforums.google.com/forum/#!topic/chromebook-central/kuW5BNJAArA
https://productforums.google.com/forum/#!topic/chromebook-central/D4mFRg3Gwak
https://productforums.google.com/forum/#!topic/chromebook-central/65bII2wo7mk

Thanks, Dennis! Let me know if you need me to look into any pieces of WebView code.

On my brand-new Chromebook Pro (canary channel), on the very latest update of moments ago, here's

THE ISSUE...

On any android App, including Google's Chrome Dev, WebViews do not scroll with two finger scrolling.  Up/Down arrows do work, and well as highlighting a portion of text and then dragging the highlight off the top/bottom of the screen.  I don't have a USB C mouse yet, so can't test the scroll wheel.

In marked contrast-- TextViews (edittext), recyclerviews, Firefox's view etc all DO scroll exactly as expected.  I haven't tried different other views, but can try on request.  Though I have to think that this is an easily reproducible issue.

NARROWED DOWN TO PLAY STORE WEBVIEW...

From playing around a bit more, I can confirm the issue is connected to the latest "Android System Webview" in the Play Store.  Uninstalling ASWV and returning to the built-in webview brings back scrolling functionality instantly to most apps I tested-- except for Google Dev/Canary (which I assume uses the newer WebView), so I'm thinking this is a fairly recent regression, which is weird since the bug was reported in March, and I have to assume the CB's Android's built-in WebView is newer than that.  But maybe not (?)

Anyway, I hope this is helpful.

Is there a list of installed apps on the Chromebook, equivalent to the android system settings "Apps" option? If so you could look in there to see what version of WebView you have after uninstalling the update.

Chrome does not use WebView at all, but it's based on the same general code, so if it's broken in WebView 58 it's probably also broken in Chrome 58 in the same way.

Still an issue in the newest Android System WebView beta version 60.0.3112.43. And the issue has now moved from beta to production as the released version is 58.0.3029.83.

Still broken on Android System WebView 61.0.3163.60. It should be possible for the WebView team to get a Chromebook running Android apps to debug this.

I can confirm that it (scrolling with touchpad on webview doesn't work) is still happening on my Acer CB 14 on unstable channel (ARC 7.1.1, System WebView 60.0.3112.116). 

When I go back to System WebView 56.0.2924.87 scrolling does work. 


As WebView is used in many apps this makes all oh them unusable on Chromebooks. 
Hope it will be fixed soon. 

I still have this bug. 

Touchpad scrolling doesn't work, but mousewheel scrolling works. The bug only occurs in certain WebView components, and only in Android apps on ChromeOS. 

For instance, in Play Newsstand, many articles scroll properly using the touchpad, but other articles will not scroll when using the touchpad. 

Asus C202SA 

Version 61.0.3163.80 (Official Build) beta (64-bit)

Workaround: 

As stated in Comment 25, uninstalling updates to the WebView restores proper touchpad scrolling functionality. 

Mine rolls back to Android System WebView version 56.0.2924.87 where the bug is no longer present.

 Issue 756529  has been merged into this issue.

Mustaq is working on a fix, details in  Issue 756529 .

It sounds like the hack at https://chromium-review.googlesource.com/c/chromium/src/+/619175 will work for now.  That seems like a reasonable short-term fix to me.  We should follow-up in a separate issue about how to get Arc++ doing something better than sending these invalid mouse events for trackpad scrolling.

Those events are actually exactly what we are expected to present to Apps, this is what touchpad scrolling is represented as in Android.
Unfortunately external touchpads are not supported on normal Android devices, instead the devices are reported as a mouse and emulate mouse wheel events. 

If we want to generate mouse wheel events for touchpads on ARC++ we will have to talk to michaelwr@ about changing the API for touchpad scroll events. Which may still be possible since ARC++ is the only provider of those as far as I am aware. 

ARC++ sends mouse wheel events for Android N or later.  See the internal bug b/63543477 #51 for links to the corresponding code.

The Motion Event spec seems to support this: the event would appear "...as a generic motion event with ACTION_SCROLL...".  See the "Device Types" section in
  https://developer.android.com/reference/android/view/MotionEvent.html

But what Dennis mentioned is also mentioned in Android documentation:
  https://developer.android.com/topic/arc/input-compatibility.html, conflicting with the Motion Event spec!

uekawa@: does this mean ARC++ can possibly follow the the alternate doc above (see #c32) instead of the Motion Event spec?  It's not clear to me which of them is more recent!

aelias@: Re your comment  http://crbug.com/756529#c8 : any clue what's the "different event type" for Blackberry Priv touchpad?

Mustaq: Mouse wheel events and the touchpad scroll gesture are distinct interactions. We do generate mouse wheel events for actual mouse wheels. 

Touchpad scroll gestures however are different and have different user-facing behavior (for example kinetic scrolling aka fling).

The Android input team specifically asked us to report touchpad scrolling as we do. If we want to change the behavior in ARC++, we have to change the spec from android input first.

michaelwr@ would the the contact to talk to about that. 

Either way, I think it would make sense to add some touchpad related notes into MotionEvent to make the distinction between mouse and touchpad scrolls clear.

Thanks Dennis for sharing the perspective of Android input team.  I agree that touchpad scrolls are different from wheel scroll.  I just want the low-level event type to be final before we start working on a proper Chromium fix.

I will ask uekawa@ to comment.

(Ooops, looks like I accidentally switched the owner in #56!)

I don't really have much domain knowledge / context here.
defer to Dennis.

I chatted with mustaq now, and we think it means ARC++ will fire when touchpad two finger scroll happens it will give Android Chrome browser 

 - ACTION_MOVE / DOWN / UP
 - touch event 
 - getButtonState() == 0
 - getToolType == TOOL_TYPE_MOUSE

plan is to have https://chromium-review.googlesource.com/c/chromium/src/+/677461 for M62, then have a proper fix for M63.

Generally I think the intention from Androids side is to have touchpad events be treated just like touch events (As they are also sent to onTouchEvent), with special behavior for when the button is pressed (for text selection for example).

Other touchpad gestures will be exposed in a similar way (such as pinch to zoom, or possibly swipe gestures). So the workaround for M62 might actually be the right start. 

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

commit 63c0627f643d6d0b7107541f63852f93b0e8921b
Author: Tobias Sargeant <tobiasjs@google.com>
Date: Fri Sep 22 17:44:05 2017

Dispatch Android touchpad events as touch events.

This is a short term fix to enable touchpad scrolling for ARC++ by
not firing mouse events for the incoming events (with
TOOL_TYPE_MOUSE) that have no button press.  Note that real mouse
events w/o buttons appear as hover events instead, so they are not
affected by this change.
https://developer.android.com/topic/arc/input-compatibility.html

Bug:  704051 
Change-Id: I7d6b9b68445000e4765d6d7b3fb293f9a7ca6b26
Reviewed-on: https://chromium-review.googlesource.com/677461
Commit-Queue: Tobias Sargeant <tobiasjs@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Alexandre Elias <aelias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503786}
[modify] https://crrev.com/63c0627f643d6d0b7107541f63852f93b0e8921b/ui/android/java/src/org/chromium/ui/base/EventForwarder.java

#34: Blackberry sends ACTION_SCROLL (mousewheel-style) events with small magnitudes.  It manages the fling animation curve on the OS side and sends a large number of small ACTION_SCROLL events.  The overall approach is quite similar to Mac OS X.  See  http://crbug.com/483231  for when Blackberry explained their approach and asked us to support it.  I've observed firsthand that Blackberry touchpads scroll smoothly with a nice decelerating curve on Chrome and other Android apps (like Settings page).

Note that I believe Blackberry needed to add code to stock Android in order to implement their behavior.  So the event model is specific to Blackberry built-in touchpads and you cannot see it by plugging in a USB touchpad to any other Android device.  In that sense, Android proper does not really have a standard way to implement touchpad scrolling, just these two competing approaches.

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

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

Thanks to tobiasjs for landing the fix here.

amineer@: ptal at our merge request.

The change landed in 63.0.3223.0, correct? Asking because touchpad scrolling still isn't working on Chrome for Android.

willg76x@gmail.com: Could you please confirm if you are talking about (i) WebView+Chromebook, or (ii) a USB trackpad connected to an Android device?  If (ii), please file a bug with your hardware details and cc me.  This bug is about only (i).

Chrombook (Kevin) running today's canary. No external device.

but it's not chromeos's version that matters here I think. It's android webview's version inside the android image?

I have no idea if that gets built along with chromeos, or is updated independently by the android play store. Presuming the latter though.

Ah. Don't have the CB on hand at the moment to provide that information.

#49 are you also running android chrome canary or dev app ?
The pre-installed version of chrome webview is something ancient like M50, that gets updated to M60 via play store.

Approved for M62 branch 3202.

#49 I had the latest beta for System Webview when I first posted.

Just gotten home and received an update for Chrome Canary for Android and that scrolls as expected.

Can confirm, this bug appears to be fixed in Chrome Canary for Android, as of 63.0.3223.7. I look forward to this fix cascading down the channels and into WebView. 

Thank you to everyone involved in getting this sorted out, it's much appreciated. 

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

commit a71ef91856202ccbe3e1c275ccf9ecf58255938b
Author: Tobias Sargeant <tobiasjs@google.com>
Date: Tue Sep 26 10:56:21 2017

Dispatch Android touchpad events as touch events.

This is a short term fix to enable touchpad scrolling for ARC++ by
not firing mouse events for the incoming events (with
TOOL_TYPE_MOUSE) that have no button press.  Note that real mouse
events w/o buttons appear as hover events instead, so they are not
affected by this change.
https://developer.android.com/topic/arc/input-compatibility.html

TBR=tobiasjs@google.com

(cherry picked from commit 63c0627f643d6d0b7107541f63852f93b0e8921b)

Bug:  704051 
Change-Id: I7d6b9b68445000e4765d6d7b3fb293f9a7ca6b26
Reviewed-on: https://chromium-review.googlesource.com/677461
Commit-Queue: Tobias Sargeant <tobiasjs@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Alexandre Elias <aelias@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#503786}
Reviewed-on: https://chromium-review.googlesource.com/684184
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#447}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/a71ef91856202ccbe3e1c275ccf9ecf58255938b/ui/android/java/src/org/chromium/ui/base/EventForwarder.java

Scrolling now works, but what about scroll dragging and swiping registered as a click on the webview? It can still be easily reproduced using the attached APK from #4.

Some experimentation (with a mouse connected to a phone) suggests that the webview behaviour is consistent with a selectable TextView in a ScrollView. Click dragging only appears to work if the TextView is not selectable. Additionally, the only reason that a Button doesn't appear to receive a click event is that there is a drag associated (both mouse and touch events).

In summary: if you want different behaviour I think you're going to have to intercept and respond appropriately to those input events.

I realize that you might want the text selection to be the default behaviour when using a mouse. But then I don't want the HTML onclick event to be fired when selecting text.

Also the example project includes a ViewPager so that you can swipe left and right between fragments containing a WebView. The ViewPager already overrides onInterceptTouchEvent by default to avoid children receiving events when swiping between fragments. But in the example APK those swipes still registers as a click on the WebView. 

What your take on this?

The click event appears to happen on desktop at the end of the selection:

http://jsbin.com/zuxedatima/edit?html,console,output

Ok!

What about the ViewPager?

Yikes, not again!

Hi zachexpress@, could you please file a new bug with as much details as possible? crbug.com/new (Please cc all the people here). 

This closed bug is about M62, so let's keep it separate.