Ignore min/max gesture bounds for mouse or stylus-derived gestures

Ignore min/max gesture bounds for mouse or stylus-derived gestures

The min/max gesture bounds are a semi-hacky workaround for unpredictable touch
devices. For mouse and stylus inputs, we should avoid applying these bounds,
preventing undesirable side-effects like tap disambiguation for mouse clicks.

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

[jdduke (slow), 2014-08-13 16:57:57]

tdresser@: PTAL, thanks.  This is a bit more wiring than I would have wanted...
I considered transforming the ToolType enum into bit flags, then using the union
in an "event_tool_types" field, but this seemed a bit simpler and gets us the
desired result.

[tdresser, 2014-08-13 17:14:12]

I'll take another look once its compiling.

Do we need to specify that we're dealing with the "primary" tool type, or can we
just refer to it as the tool type?

I'm not sure when we'd have multiple tool types in play simultaneously.

https://codereview.chromium.org/468043003/diff/1/ui/events/gesture_detection/...
File ui/events/gesture_detection/touch_disposition_gesture_filter.cc (right):

https://codereview.chromium.org/468043003/diff/1/ui/events/gesture_detection/...
ui/events/gesture_detection/touch_disposition_gesture_filter.cc:20:
MotionEvent::ToolType primary_tool_type,
Is there a non-primary tool type sometimes?

[jdduke (slow), 2014-08-13 17:30:08]

On 2014/08/13 17:14:12, tdresser wrote:
> I'll take another look once its compiling.
> 
> Do we need to specify that we're dealing with the "primary" tool type, or can
we
> just refer to it as the tool type?
> 
> I'm not sure when we'd have multiple tool types in play simultaneously.
> 

I don't think that assumption is made explicit anywhere, and I'm not sure
Android guarantees that (otherwise they'd just have a GetToolType() instead of a
GetToolType(pointer_index)). I'd hesitate to just call it tool_type without any
modifier as it's somewhat misleading.

https://codereview.chromium.org/468043003/diff/1/ui/events/gesture_detection/...
File ui/events/gesture_detection/touch_disposition_gesture_filter.cc (right):

https://codereview.chromium.org/468043003/diff/1/ui/events/gesture_detection/...
ui/events/gesture_detection/touch_disposition_gesture_filter.cc:20:
MotionEvent::ToolType primary_tool_type,
On 2014/08/13 17:14:11, tdresser wrote:
> Is there a non-primary tool type sometimes?

There are no guarantees that all pointers will have the same tool type.

[tdresser, 2014-08-13 17:53:12]

LGTM.

[jdduke (slow), 2014-08-13 17:56:04]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-08-13 17:57:30]

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

[commit-bot: I haz the power, 2014-08-13 21:49:55]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_aosp on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_aosp/bu...)
  linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[commit-bot: I haz the power, 2014-08-14 00:10:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-08-14 00:10:45]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[jdduke (slow), 2014-08-14 00:21:54]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-08-14 00:23:48]

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

[commit-bot: I haz the power, 2014-08-14 07:09:22]

Committed patchset #2 (20001) as 289477