[Android] Properly disable the touch ack timeout during a touch sequence

[Android] Properly disable the touch ack timeout during a touch sequence

This issue was recently uncovered by the interaction of touch-action:none
when disabling the touch timeout.  In that case, the disable command did not
actually take effect until the following touch sequence (if one was active).
Instead, forcefully disable the timeout/timer for the current touch sequence
when the TouchEventQueue is commanded to do so.

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

[jdduke (slow), 2014-03-06 21:14:38]

PTAL.  A little embarrassing that we haven't caught this until now.  Turns out
the deferred enabling "feature" also applied to disabling...

Note that we *could* enable the timeout mid-sequence, but I prefer it being
delayed until the subsequent sequence (the current behavior).

[Rick Byers, 2014-03-06 22:46:11]

LGTM
We may want to make the timing based testing more clearly immune to flake, but
I'm fine with that coming in a later CL.

https://codereview.chromium.org/188833004/diff/20001/content/browser/renderer...
File content/browser/renderer_host/input/touch_event_queue_unittest.cc (right):

https://codereview.chromium.org/188833004/diff/20001/content/browser/renderer...
content/browser/renderer_host/input/touch_event_queue_unittest.cc:1032:
Wait(base::TimeDelta::FromMilliseconds(kDefaultTouchTimeoutDelayMs * 2));
To what extent do you believe this is immune from timing-related flakiness? 
This should guarantee that the timeout fires, but what about the inverse - is
the timeout guaranteed not to fire before we expect it too (eg. on a bot under
heavy load)?

I guess since we're not pumping the message loop it should be fine (even if the
timer expires early, we won't see any effect until we're ready for it and pump
the loop by calling wait).  If that's true, then shouldn't we be able to use a
0ms (or 1ms if 0 is handled synchronously) timeout which will both be faster and
more clearly non-flaky than using an apparently magic value of 10ms?

[jdduke (slow), 2014-03-06 22:52:19]

https://codereview.chromium.org/188833004/diff/20001/content/browser/renderer...
File content/browser/renderer_host/input/touch_event_queue_unittest.cc (right):

https://codereview.chromium.org/188833004/diff/20001/content/browser/renderer...
content/browser/renderer_host/input/touch_event_queue_unittest.cc:1032:
Wait(base::TimeDelta::FromMilliseconds(kDefaultTouchTimeoutDelayMs * 2));
On 2014/03/06 22:46:11, Rick Byers wrote:
> To what extent do you believe this is immune from timing-related flakiness? 
> This should guarantee that the timeout fires, but what about the inverse - is
> the timeout guaranteed not to fire before we expect it too (eg. on a bot under
> heavy load)?
> 
> I guess since we're not pumping the message loop it should be fine (even if
the
> timer expires early, we won't see any effect until we're ready for it and pump
> the loop by calling wait).  If that's true, then shouldn't we be able to use a
> 0ms (or 1ms if 0 is handled synchronously) timeout which will both be faster
and
> more clearly non-flaky than using an apparently magic value of 10ms?

This isn't just spinning.  We post a delayed quit task which is guaranteed to be
ordered properly w.r.t. the already posted timeout task.  Then we run the
message loop, which will block until it dispatches the posted quit task. As far
as I'm aware, these tests have never flaked, and we could probably shorten the
timeout without any loss.

[jdduke (slow), 2014-03-06 23:41:45]

I've reduced all of the timeouts, and double-checked that these specific
timeout-based tests should (should... =/) not be subject to potential
false-positive timeouts.

[jdduke (slow), 2014-03-06 23:41:48]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-03-06 23:45:18]

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

[commit-bot: I haz the power, 2014-03-07 08:55:46]

Change committed as 255555