Expose whether a touch event may cause scrolling if uncanceled

Expose whether a touch event may cause scrolling if uncanceled

Currently, there are several parts of the touch pipeline that need to
know whether a touch event may cause scrolling. In particular, touchmove
events within a platform-specific slop region will not induce
scrolling, and such events are suppressed by the TouchEventQueue when
the touchstart is not prevented. The TouchEventQueue uses a slop region
constant to perform this suppression.

However, there are no guarantees that this constant is the same as that
used in gesture detection. With devtools touch emulation, it should be
possible to vary the slop region when emulating different devices, but
the duplicated slop region code in the TouchEventQueue makes this
difficult.

This solution tags each touch event with a bit indicating whether
the event may cause scrolling, allowing any listener or consumer of the
touch stream to better reason about the touch event's default action.
This tagging will be wired up in the corresponding Chromium change:
https://codereview.chromium.org/718153002

Also remove the IsLastInputEventForCurrentVSync flag as it's no
longer used.

BUG=425586
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=185244

[jdduke (slow), 2014-11-07 22:51:42]

jdduke@chromium.org changed reviewers:
+ rbyers@chromium.org

[jdduke (slow), 2014-11-07 22:51:42]

rbyers@: PTAL. If you prefer, we can add a separate flags field just for touch
events, where we can tag it with data like cancelable/maycausescrolling/etc...
(maybe the other generated gesture types in the future?)

[Rick Byers, 2014-11-10 18:56:04]

lgtm with nit.

Sigh, this stupid "can't use bool in IPC objects" thing should really be fixed
properly at some point.  I don't think it's worth converting to flags right now,
but I suspect we'll want to generalize this 'may cause scrolling' to a set of
'may cause gesture X' bits (eg. see
https://bugs.webkit.org/show_bug.cgi?id=138151).  At that time we should pack
all these bits nicely one way or the other.

https://codereview.chromium.org/702883004/diff/20001/public/web/WebInputEvent.h
File public/web/WebInputEvent.h (right):

https://codereview.chromium.org/702883004/diff/20001/public/web/WebInputEvent...
public/web/WebInputEvent.h:495: int mayCauseScrollingIfUncanceled;
Nit: if it really "will be true for ..." then why call it "may..."?  Maybe just
"causesScrollingIfUncanceled"?

Do you plan to take the touch-action filter into account in setting this bit?

[jdduke (slow), 2014-11-10 19:13:02]

On 2014/11/10 18:56:04, Rick Byers wrote:
>
https://codereview.chromium.org/702883004/diff/20001/public/web/WebInputEvent.h
> File public/web/WebInputEvent.h (right):
> 
>
https://codereview.chromium.org/702883004/diff/20001/public/web/WebInputEvent...
> public/web/WebInputEvent.h:495: int mayCauseScrollingIfUncanceled;
> Nit: if it really "will be true for ..." then why call it "may..."?  Maybe
just
> "causesScrollingIfUncanceled"?
> 

Well, I guess because the semantics of "causesScrolling" may not be clear, e.g.,
it may produce a scroll event but may not induce scrolling (overscroll,
touch-action). The alternative is a negative bit "wontCauseScrolling" for events
that we know won't produce any kind of scrolling (touchmove's within the slop
region). I'll rename to |causesScrollingIfUncanceled| and make it clear that we
mean "causesScrolling ~ generates scroll events".


> Do you plan to take the touch-action filter into account in setting this bit?

Good point, yes.

[Rick Byers, 2014-11-10 19:26:46]

On 2014/11/10 19:13:02, jdduke wrote:
> On 2014/11/10 18:56:04, Rick Byers wrote:
> >
>
https://codereview.chromium.org/702883004/diff/20001/public/web/WebInputEvent.h
> > File public/web/WebInputEvent.h (right):
> > 
> >
>
https://codereview.chromium.org/702883004/diff/20001/public/web/WebInputEvent...
> > public/web/WebInputEvent.h:495: int mayCauseScrollingIfUncanceled;
> > Nit: if it really "will be true for ..." then why call it "may..."?  Maybe
> just
> > "causesScrollingIfUncanceled"?
> > 
> 
> Well, I guess because the semantics of "causesScrolling" may not be clear,
e.g.,
> it may produce a scroll event but may not induce scrolling (overscroll,
> touch-action). The alternative is a negative bit "wontCauseScrolling" for
events
> that we know won't produce any kind of scrolling (touchmove's within the slop
> region). I'll rename to |causesScrollingIfUncanceled| and make it clear that
we
> mean "causesScrolling ~ generates scroll events".

Perfect, thanks.  

> > Do you plan to take the touch-action filter into account in setting this
bit?
> 
> Good point, yes.

Please add a link in the description to the patch that sets this bit (once you
finish teasing that apart from your new Android UI).

[jdduke (slow), 2014-11-12 19:13:19]

jdduke@chromium.org changed reviewers:
+ aelias@chromium.org

[jdduke (slow), 2014-11-12 19:13:20]

Adding aelias@ for the Source/web/WebInputEvent.cpp change.

[aelias_OOO_until_Jul13, 2014-11-12 19:23:17]

lgtm

[jdduke (slow), 2014-11-12 19:46:32]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-11-12 19:47:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/702883004/40001

[commit-bot: I haz the power, 2014-11-12 20:58:46]

Committed patchset #3 (id:40001) as 185244