The root problem here is specific to ARC++ relying on bogus mouse events for their trackpad scrolling, right?  As long as ARC++ is doing something different from any other Android platform we're going to have hard-to-diagnose brittleness like in  issue 704051  (eg. I assume we're not likely to have any bots setup to test ToT chromium WebView with ARC++?).

aelias@ suggested elsewhere that the right fix is for ARC++ to switch to using the same trackpad scrolling behavior as blackberry devices do (ACTION_SCROLL).  Dennis, WDYT - Is that the right path forward here?

To clarify, it's ARC++ that's GENERATING the button-less mouse events we've tried to detect with the fix in  issue 704051 , right?  Or is there actually something in Android itself?

We (Dennis, Junichi and I) discussed this while in TOK.  In fact, the "bogus-looking mouse-event sent as a touch event" is what Android team prefers as the correct trackpad scroll event (although their documentation seems to support wheels too).  Since it's the Android team to decide the low-level event type, we agreed that ARC++ team would instead stop firing ACTION_SCROLL!

There has been a lot of confusion here.  I suggest: let's meet to clear it out.

As mustaq said, this is the behavior that the Android team prefers, and we have to follow it on ARC++.

I think the overall idea behind this is that a touchpad is a mouse with gestures. And gestures are reported not by emulating a touchscreen. 

It is confusing for scroll events since there is an equivalent ACTION_SCROLL event that is being used for mouse wheel scrolling, but it makes a little more sense when looking further towards pinch-to-zoom or swipe gestures, which will be generated to look like touch events as well.

I'd be happy to chat more about it in a meeting. However I can't really say much about the motivation behind the design of these events, since on the ARC++ side, we are just following the specs given to us. We should schedule some time with michaelwr@ if that's something you would like to learn more about. 

I had a typo there: And gestures are reported *not* by emulating a touchscreen. 

should be: And gestures are reported by emulating a touchscreen.  

ARC++ documentation about this is here: https://developer.android.com/topic/arc/input-compatibility.html

Mustaq tells me this is the event sequence the Android input team wants.  I guess I can see how it might not be a complete hack if you consider that in most Android apps the mouse behaves similar to a touchscreen (click and drag scrolls).  But I can't find any mention of it in the Android API docs.  Perhaps the "devices types" section of https://developer.android.com/reference/android/view/MotionEvent.html should be updated?

At the moment the docs seem to suggest ACTION_SCROLL as the "right" way to represent trackpad scrolling.  That is what BlackBerry devices do, and we fixed Chrome years ago ( issue 483231 ) to work well in that model.

If onTouchEvent with SOURCE_MOUSE is really what Android wants to use for touchpad scrolling, then I think there are a number of details that need to be defined.  For example, does this mean it's now possible to get co-ordinate values that exceed the getMotionRange bounds (such as when scrolling up when the cursor is at the top of the screen), or will getMotionRange return bounds larger than the screen?

The other thing to consider here (at the summary describes) is whether and how web pages can intercept these events.  There are many sites like Google Sheets which do all their own scrolling in JavaScript by intercepting the low level events (wheel, touch*).  Is it reasonable for those sites to just be unusable with a touchpad?  In the ACTION_SCROLL model, Chrome would generate wheel events (same as ChromeOS/MacOS touchpad).  In the SOURCE_MOUSE model we don't generate any JS events.  

These two questions (what Android/ARC++ expose to Android apps, and what Chrome exposes to the web) are of course orthogonal.  If necessary we can add code to Chrome to convert from one model to another.  But by default the model chosen at the Android layer will determine which code path gets hit in all existing Android browsers.

Thanks Dennis.  Considering the other gestures as well makes this make more sense to me.  I'd feel a lot better about this if it was documented somewhere in the Android docs so that all Android apps know it's something to be aware of and we know the answers to the edge cases like the screen boundary question I raised above.  Can you ask michaelwr@ to get this documented in the MotionEvent API docs?

I'd also feel a lot better about this if it was possible to plug in some external  touchpad and see this behavior in stock Android.  I've done testing before with a USB touchpad plugged into my phone, and I've only ever noticed ACTION_SCROLL events (which most apps handle pretty terribly).  Perhaps we can get a bug filed on Android to make at least SOME device work the way this is described on stock Android?

We have briefly discussed the best model to use at the Android/ARC++ level, and my first impression is that (Blackberry-like) ACTION_SCROLL events is a possibility there.  So let's wait until we have a fix in ARC++.

We will soon have an internal bug for it.

Here is the internal bug tracking ARC++ level events: b/67300262

Still waiting for ARC++/Android decision.  Moving the target milestone to M-64.

We need to fix the CrOS low-level bugs before we can do anything reasonable here.