Lock element at start of gesture sequence.

Lock element at start of gesture sequence.

Currently a separate hit test is performed for every gesture event and because
of touch fuzzing, a show press can land on a separate element than a tap down.
This change locks the gesture sequence to the element hit on tap down until
another tap down / scroll.

BUG=226842

[Rick Byers, 2014-02-21 03:46:54]

Unfortunately I think getting this right is going to be a little more involved
:-(  (unless I'm missing something).

https://codereview.chromium.org/130433009/diff/50001/Source/core/page/EventHa...
File Source/core/page/EventHandler.cpp (right):

https://codereview.chromium.org/130433009/diff/50001/Source/core/page/EventHa...
Source/core/page/EventHandler.cpp:2311: Element* gestureElement =
m_elementHandlingGestureSequence.get();
I don't think this handles all the cases (or even the most likely cases).  Eg.
what if tapDown causes a new element to appear over top of the element.  I think
we decided we want the tap to still go to the original (i.e. highlighted)
element, even though a hit test at it's co-ordinates would now reach the element
on top.

So I think you need to find a way to skip the hit test entirely and used the
cached element.

https://codereview.chromium.org/130433009/diff/50001/Source/core/page/EventHa...
Source/core/page/EventHandler.cpp:2321: m_elementHandlingGestureSequence =
result.innerElement();
you probably don't want to hold on to this indefinitely (could keep an expensive
tree of objects alive for a long time), but it's not obvious to know when to
release it.  The simple case is on Tap and GestureScrollEnd, but I think there
are some more subtle cases (eg. multi-finger swipe).

Perhaps you should just treat a tap sequence (TapDown...Tap/TapCancel) and a
scroll sequence (ScrollBegin...ScrollEnd) as independent sequences.  I guess
this boils down to how we want things to behave if ShowPress triggers a
scrollable element to appear on top - does pressing then scrolling scroll the
new element or the background one?  It would be valuable to know the behavior of
different browsers here.

Worst case we could add a GestureEnd.

https://codereview.chromium.org/130433009/diff/50001/Source/core/page/EventHa...
File Source/core/page/EventHandler.h (right):

https://codereview.chromium.org/130433009/diff/50001/Source/core/page/EventHa...
Source/core/page/EventHandler.h:380: RefPtr<Node> m_scrollGestureHandlingNode;
can we merge this in with your more general mechanism?