I think this is implemented in browser because long-press and move might interfere with scrolling. So it handle the move MotionEvent before gesture_provider.

eirage@, what do you mean by scrolling?

I was thinking that we could introduce a new gesture maybe called ET_GESTURE_LONG_PRESS_DRAG. This gesture would be trigggered if a user dragged after a long-press. This event would be sent to Blink which would take care of selecting text. After the user is done dragging we'd get the existing event ET_GESTURE_LONG_TAP. On the long-tap we would show the touch handles and the selection quick menu.

We shouldn't get a 'tap' event if the touch-point moved beyond the tap-threshold, which would be the case for drags like this, right?

We shouldn't get a 'tap' in this scenario but I think we should get a long-tap. A long-tap happens when you lift your finger after a long-press. Right now long-tap's are never sent in Android (I believe because of the long-press drag selector crbug.com/807426). This is a problem because the selection handles and selection menu are supposed to be shown on long-tap. If you try long-pressing text in a native Android TextView the touch handles and floating menu only appear after you lift your finger off the screen.

I think the "finger down + move" currently generates ET_GESTURE_SCROLL_BEGIN and ET_GESTURE_SCROLL_UPDATE. 
Consider user might put their finger on and empty area for a few second and then start to move to scroll the page.
If we introduce ET_GESTURE_LONG_PRESS_DRAG, gesture provider must know what element the finger is on to decide whether scroll or drag. I don't know if it's good to do that.

What if we notify the gesture provider if a long-press was consumed and only trigger ET_GESTURE_LONG_PRESS_DRAG if it was consumed? We already have a gesture event acks which say whether the gesture event was consumed.

In that case, having an extra drag gesture sounds great to me. This gesture may also be use to initialize touch drag-and-drop. :D
We can probably make scrollupdates pending on both touch ack and long-press ack (if long press sent) 

My only concern is this may delay sending the scroll events, will it increase scroll latency?

+tdresser@ for his opinion.

I'm pretty sure there's a good reason this is in the browser, but I can't completely recall why.

I know there were some issues with composited scrolling, and selection handles not sticking in place.

+Folks who might remember. If we don't get an answer, I recommend following up with mohsen@, mfomitchev@ and sadrul@ via email.

I think the selection handles aren't an issue in this case since they would only appear after the long-press drag selection completes (when your finger leaves the screen).

Re C#14, agreed.

The issues with selection handles and scrolling should be fixed, with the exception of iframes on Android, as there are still issues with the coordinate transform functions doing the wrong thing there.