[Android] Always offer touchmove's for events with multiple pointers

[Android] Always offer touchmove's for events with multiple pointers

Previously, touchmove's would be suppressed for non prevent-default'ed touch
sequences until the touchmove exceeded the slop threshold.  This led to issues
where touchmove's for a secondary pointer would never be forwarded while the
primary pointer was stationary.  As slop event suppression is really an
optimization of scrolling with a single pointer, simply enable forwarding of
touchmove's if there are multiple pointers present in the MotionEvent.

BUG=135102
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=244063

[jdduke (slow), 2014-01-09 02:19:55]

skyostil@: What do you think?  I considered tracking secondary pointer touch
slop regions, but honestly I think this is sufficient for the common case
(preventing TouchMove's within the slop region during a one-fingered scroll).

[tdresser, 2014-01-09 13:30:51]

On 2014/01/09 02:19:55, jdduke wrote:
> skyostil@: What do you think?  I considered tracking secondary pointer touch
> slop regions, but honestly I think this is sufficient for the common case
> (preventing TouchMove's within the slop region during a one-fingered scroll).

In order for n finger tap to work, you need a touch slop region for every touch.
Since we're planning on unifying the Android and Aura GRs, it probably makes
sense to do this correctly now.

[Rick Byers, 2014-01-09 15:40:15]

On 2014/01/09 13:30:51, tdresser wrote:
> On 2014/01/09 02:19:55, jdduke wrote:
> > skyostil@: What do you think?  I considered tracking secondary pointer touch
> > slop regions, but honestly I think this is sufficient for the common case
> > (preventing TouchMove's within the slop region during a one-fingered
scroll).
> 
> In order for n finger tap to work, you need a touch slop region for every
touch.
> Since we're planning on unifying the Android and Aura GRs, it probably makes
> sense to do this correctly now.

Good catch.  For context, Aura currently uses two-finger tap as a context-menu
shortcut.  We could debate whether or not we should keep this discrepancy with
Android, but I agree we should be able to support such gestures.  But since this
CL here is only in the java code, I'm not sure it's worth the effort to fix it
here.  We can track this as one of the things we know we'll need to do for
unified GR.

[jdduke (slow), 2014-01-09 15:49:29]

On 2014/01/09 15:40:15, Rick Byers wrote:
> On 2014/01/09 13:30:51, tdresser wrote:
> > On 2014/01/09 02:19:55, jdduke wrote:
> > > skyostil@: What do you think?  I considered tracking secondary pointer
touch
> > > slop regions, but honestly I think this is sufficient for the common case
> > > (preventing TouchMove's within the slop region during a one-fingered
> scroll).
> > 
> > In order for n finger tap to work, you need a touch slop region for every
> touch.
> > Since we're planning on unifying the Android and Aura GRs, it probably makes
> > sense to do this correctly now.
> 
> Good catch.  For context, Aura currently uses two-finger tap as a context-menu
> shortcut.  We could debate whether or not we should keep this discrepancy with
> Android, but I agree we should be able to support such gestures.  But since
this
> CL here is only in the java code, I'm not sure it's worth the effort to fix it
> here.  We can track this as one of the things we know we'll need to do for
> unified GR.

Ah, right.  As the current Android pipeline doesn't (explicitly) support
multi-finger tap, this code may look quite a bit different in the unified GR. 
Looks like we have that point covered in the doc, thanks.

[jdduke (slow), 2014-01-09 18:22:23]

Hmm, looks like Sami may be out.

wangxianzhu@: Would you mind taking a look? I moved the touch-move confirmation
code out of LongPressDetector, as it was honestly an odd place for that code to
exist (it didn't affect internal LongPressDetector behavior in any way). Thanks.

[Xianzhu, 2014-01-09 21:54:32]

lgtm.

https://codereview.chromium.org/129783004/diff/110001/content/public/android/...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewGestureHandler.java
(right):

https://codereview.chromium.org/129783004/diff/110001/content/public/android/...
content/public/android/java/src/org/chromium/content/browser/ContentViewGestureHandler.java:946:
if (event.getPointerCount() > 1) mTouchMoveToNativeConfirmed = true;
Nit: The following should be put in an else block to avoid unnecessary
calculation when event.getPointerCount() > 1.

[commit-bot: I haz the power, 2014-01-09 22:33:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/129783004/240001

[jdduke (slow), 2014-01-09 22:37:34]

https://codereview.chromium.org/129783004/diff/110001/content/public/android/...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewGestureHandler.java
(right):

https://codereview.chromium.org/129783004/diff/110001/content/public/android/...
content/public/android/java/src/org/chromium/content/browser/ContentViewGestureHandler.java:946:
if (event.getPointerCount() > 1) mTouchMoveToNativeConfirmed = true;
On 2014/01/09 21:54:32, Xianzhu wrote:
> Nit: The following should be put in an else block to avoid unnecessary
> calculation when event.getPointerCount() > 1.

Done.

[commit-bot: I haz the power, 2014-01-10 00:35:37]

Retried try job too often on linux_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_aura...

[commit-bot: I haz the power, 2014-01-10 01:47:00]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/129783004/240001

[commit-bot: I haz the power, 2014-01-10 03:06:26]

Change committed as 244063

[Sami, 2014-01-10 11:02:27]

lgtm fwiw.