Note that the autoscroll feature is currently behind a flag in Android.

Renaming the bug to reflect the immediate goal.

I think this is a nongoal since middle-click autoscroll is a Windows-specific UI.

Middle click autoscroll browsertests that I wrote are failing on Android due this bug. Now that we support middle click autoscroll on all other platforms. Do we still want to keep this as wontFix?

Yes, I agree we should fix this: mouse is no longer an alien for Android apps.  

I think the only some UI work is needed here: showing a "scroll-thumb" like in Windows.

A quick note on device dependence: Samsung devices used to intercept middle-button as home-button (last checked ~2 years ago).  Worth checking if this is still the case.

We did enable it on Mac but not Linux (Linux already has a middle click action, paste). I think this is a per platform decision so someone from Android UX should make a call whether this is something they want. Ted, do you know who that'd be?

Adding Ben,

This looks like something that could be aded from the framework side, @Ben, do you know who would be a good person to talk to there?

If it's not the ARC++ team, +Evan might know if there's someone on the platform team that owns mouse input.

+phshah@ for ui-toolkit.

I don't know if there is anyone in Android UX who thinks about mouse/kb, I thought our UX was kinda driving mouse/keyboard/desktop stuff.

However, you may want to consult with Android's UI-toolkit team (chet@ and/or adamp@) to see if they have thoughts around this autoscroll behavior and how it might fit into their work.

Yeah, I don't think anyone on Android UX does. We can make determinations about mouse on our end, but I think this bug is about Clank. In either case I think Android should weigh in on this kind of interaction and UI toolkit eng, like Evan suggested, is probably the best place to start.

My thinking on this topic is that we should try to be consistent with whatever scroll logic text view would want to do with middle click.

I wonder if WebView is actually a more important case than Chrome (targeting Chrome OS Android apps).

I don't think this will be a high priority for the Chrome Android team though, so I don't know if we'd get UX resourcing to scope this out to make it specific to Chrome's behavior.  I don't think you'd likely get strong objections if you wanted to go forward and implement the necessary UI, but I don't know if it will ever bubble up high enough in priority to do anything but a personal interest expedition.

Closing the bug based on the last comment.

Since Chrome OS Android apps are more important use-case here, we will reopen this bug only if ChromeOS ever ships autoscroll.