(NOT FOR REVIEW) Distinguish between touch and touchmove handler presence

(NOT FOR REVIEW) Distinguish between touch and touchmove handler presence

Currently, the renderer communicates a single bit about the presence
of touch handlers to the browser. This is used to avoid unnecessarily
sending touch events to the renderer when there are no appropriate
handlers.

However, it has been observed that a non-trivial number of sites add
touchstart handlers but no *touchmove* handlers. As dispatch of the
first touchmove to the renderer main thread can block scrolling, this
means we're unnecessarily blocking scrolling for sites that lack a
touchmove handler, increasing the risk of jank and scroll delay.

Instead, notify the WebWidgetClient when the existence of a particular
handler class has changed. This includes touch, touchmove, wheel and
scroll handlers. The embedder can then take the appropriate action to
optimize the non-existent touchmove handler case (as in
crrev.com/1050993004).

BUG=464721

[jdduke (slow), 2015-09-02 21:59:10]

+tdresser, Not sending this out for review, just an FYI as you were curious
about the patch.

I really don't like this :(. It was probably the simplest approach to get
something working, as I didn't want to muck about too much with
EventHandlerRegistery internals. However, the right thing to to is probably
abstract the concept of an "EventHandlerClass" to allow finger grained buckets
internally within the EventHandlerRegistry. There's also the question of whether
we should tell the browser about touchend/touchcancel existence. It's probably
not necessary, but it might be cleaner on the implementation side.

[jdduke (slow), 2015-09-02 22:02:02]

Patchset #4 (id:60001) has been deleted

[jdduke (slow), 2015-09-02 22:03:03]

https://codereview.chromium.org/1055683003/diff/100001/Source/core/page/Chrom...
File Source/core/page/ChromeClient.h (right):

https://codereview.chromium.org/1055683003/diff/100001/Source/core/page/Chrom...
Source/core/page/ChromeClient.h:199: virtual void needTouchEvents(bool) = 0;
We should probably just change the bool arg to a bit field that indicates all
the needed touch types.

[tdresser, 2015-09-03 13:18:32]

On 2015/09/02 22:03:03, jdduke wrote:
>
https://codereview.chromium.org/1055683003/diff/100001/Source/core/page/Chrom...
> File Source/core/page/ChromeClient.h (right):
> 
>
https://codereview.chromium.org/1055683003/diff/100001/Source/core/page/Chrom...
> Source/core/page/ChromeClient.h:199: virtual void needTouchEvents(bool) = 0;
> We should probably just change the bool arg to a bit field that indicates all
> the needed touch types.

What kind of implementation cleanup do you think we'd see if we also told the
browser about touchend/touchcancel?

I think it's probably simpler for EventHandlerClass to store event types at
different levels of granularity, otherwise there would be a bunch of cases
called out explicitly that we don't differentiate.

If this is true, then I'm not sure what splitting out touchend/touchcancel buys
us.

[jdduke (slow), 2015-09-03 15:50:38]

On 2015/09/03 13:18:32, tdresser wrote:
> What kind of implementation cleanup do you think we'd see if we also told the
> browser about touchend/touchcancel?
> 

Not much, and it probably wouldn't be much of an optimization either.

> I think it's probably simpler for EventHandlerClass to store event types at
> different levels of granularity, otherwise there would be a bunch of cases
> called out explicitly that we don't differentiate.
> 

Yeah, that's the tricky balance here. We really only care about the touchmove
case, but it's still a bit awkward to have 2 separate classes for touch events.
I was thinking of doing just as you said, having a separate granularity for how
we store the events (so there's just one touchevent class, but we have
touch/touchmove storage). The trick bit there is that there's a call to get the
EventTargetSet by *class*. There's only one caller of that method, but I didn't
see a simple way of adjusting that method short of getting cute with custom
iterators, or just doing what I'm doing now and making the caller aware of the
touch/touchmove distinction.

> If this is true, then I'm not sure what splitting out touchend/touchcancel
buys
> us.

Not a lot probably.