Add gestureFlingStart to gestures that can cancel a deferred tapDown

Add gestureFlingStart to gestures that can cancel a deferred tapDown

It looks like there are cases where we might get a tapDown followed by a flingStart
immediately without and scrollBegin from the Android framework. To avoid using the
tapDown in these situations have flingStart also remove the deferred tapDown like
scrollBegin and pinchBegin

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

[aelias_OOO_until_Jul13, 2012-11-28 23:13:45]

How does this happen?  The Android framework delays for 1xx milliseconds, then
sends a ShowPressState and FlingStart in a single batch?  Why didn't it send the
FlingStart before the ShowPressState timeout?

[Yusuf, 2012-11-28 23:28:09]

This is currently happening for Chrome for Android mostly because of the delay
we are incurring from all the touch events travelling to WebKit and getting
back. When there is a more than 150 ms delay between receiving the touch event
after touchDown, Android is sending the SHOW_PRESS gesture and then the fling
after it gets the touchUp.

So technically this should go away with the touch event handler region fix, or
occur much less frequently. But since currently gesture_event_filter assumes
every flingStart should have scrollBegin before it, I saw this as something that
should be fixed to avoid any weird behavior that we can't foresee. Also I think
rjkroege@ mentioned touchPad(?) flings might also not occur without scrollBegin.

On 2012/11/28 23:13:45, aelias wrote:
> How does this happen?  The Android framework delays for 1xx milliseconds, then
> sends a ShowPressState and FlingStart in a single batch?  Why didn't it send
the
> FlingStart before the ShowPressState timeout?

[rjkroege, 2012-11-29 15:32:06]

there is something wrong with codereview: it says that there is no valid chunk
for the diff? Yusuf: maybe you could upload again?

On 2012/11/28 23:28:09, Yusuf wrote:
> This is currently happening for Chrome for Android mostly because of the delay
> we are incurring from all the touch events travelling to WebKit and getting
> back. When there is a more than 150 ms delay between receiving the touch event
> after touchDown, Android is sending the SHOW_PRESS gesture and then the fling
> after it gets the touchUp.
> 
> So technically this should go away with the touch event handler region fix, or
> occur much less frequently. But since currently gesture_event_filter assumes
> every flingStart should have scrollBegin before it, I saw this as something
that
> should be fixed to avoid any weird behavior that we can't foresee. Also I
think
> rjkroege@ mentioned touchPad(?) flings might also not occur without
scrollBegin.

afaik: touchpad flings do not have scrollbegins. But they shouldn't be going
through the GestureEventFilter -- yet another reason for
https://bugs.webkit.org/show_bug.cgi?id=103551

> 
> On 2012/11/28 23:13:45, aelias wrote:
> > How does this happen?  The Android framework delays for 1xx milliseconds,
then
> > sends a ShowPressState and FlingStart in a single batch?  Why didn't it send
> the
> > FlingStart before the ShowPressState timeout?

[Yusuf, 2012-11-29 19:12:30]

Can you take a look at it again? I can see it this time.

[rjkroege, 2012-11-29 22:06:51]

did you test on CrOS?

lgtm

[commit-bot: I haz the power, 2012-11-30 18:17:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yusufo@chromium.org/11418218/4

[commit-bot: I haz the power, 2012-11-30 21:07:41]

Retried try job too often on win_rel for step(s) browser_tests

[commit-bot: I haz the power, 2012-11-30 21:21:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yusufo@chromium.org/11418218/4

[commit-bot: I haz the power, 2012-11-30 22:56:55]

Change committed as 170583