Lock element at start of gesture sequence.

Source/core/page/EventHandler.cpp

Index: Source/core/page/EventHandler.cpp
diff --git a/Source/core/page/EventHandler.cpp b/Source/core/page/EventHandler.cpp
index c6a95286d46fbb6b5997fb4a96e026649f9672a7..7fd46517728a2b3a06fa86b0bc37a1ce8e155dab 100644
--- a/Source/core/page/EventHandler.cpp
+++ b/Source/core/page/EventHandler.cpp
@@ -355,6 +355,7 @@ void EventHandler::clear()
     m_mouseDownMayStartDrag = false;
     m_lastShowPressTimestamp = 0;
     m_lastDeferredTapElement = 0;
+    m_elementHandlingGestureSequence = 0;
 }
 
 void EventHandler::nodeWillBeRemoved(Node& nodeToBeRemoved)
@@ -2304,9 +2305,21 @@ bool EventHandler::handleGestureEvent(const PlatformGestureEvent& gestureEvent)
         hitType |= HitTestRequest::Active | HitTestRequest::ReadOnly;
 
     if ((!scrollbar && !eventTarget) || !(hitType & HitTestRequest::ReadOnly)) {
-        IntPoint hitTestPoint = m_frame->view()->windowToContents(adjustedPoint);
+        IntPoint hitTestPoint;
+        // FIXME: Track element across iframes when out of process iframes have more structure.
+        if (m_elementHandlingGestureSequence && gestureEvent.type() != PlatformEvent::GestureTapDown) {
+            Element* gestureElement = m_elementHandlingGestureSequence.get();

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

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.

+            hitTestPoint.setX((gestureElement->offsetLeft() + gestureElement->offsetWidth()) / 2);
+            hitTestPoint.setY((gestureElement->offsetTop() + gestureElement->offsetHeight()) / 2);
+        } else {
+            hitTestPoint = m_frame->view()->windowToContents(adjustedPoint);
+        }
+
         HitTestResult result = hitTestResultAtPoint(hitTestPoint, hitType | HitTestRequest::AllowFrameScrollbars);
 
+        if (gestureEvent.type() == PlatformEvent::GestureTapDown)
+            m_elementHandlingGestureSequence = result.innerElement();

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

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.

+
         if (shouldKeepActiveForMinInterval) {
             m_lastDeferredTapElement = result.innerElement();
             m_activeIntervalTimer.startOneShot(minimumActiveInterval - activeInterval);
@@ -2322,6 +2335,8 @@ bool EventHandler::handleGestureEvent(const PlatformGestureEvent& gestureEvent)
     }
 
     if (scrollbar) {
+        // If finger was on scrollbar, it will be locked by the scroll handling code.
+        m_elementHandlingGestureSequence = 0;
         bool eventSwallowed = scrollbar->gestureEvent(gestureEvent);
         if (gestureEvent.type() == PlatformEvent::GestureTapDown && eventSwallowed) {
             m_scrollbarHandlingScrollGesture = scrollbar;