Add hittest mode for Touch-action which ignore inline elements and svg elements

Source/web/tests/TouchActionTest.cpp

Index: Source/web/tests/TouchActionTest.cpp
diff --git a/Source/web/tests/TouchActionTest.cpp b/Source/web/tests/TouchActionTest.cpp
index 9cb4f7c3513d232af60559ef933150aee7c593b9..b4ccceff40dfd8c2f5d1a184596eba86b8e6d9a5 100644
--- a/Source/web/tests/TouchActionTest.cpp
+++ b/Source/web/tests/TouchActionTest.cpp
@@ -169,7 +169,7 @@ WebView* TouchActionTest::setupTest(std::string file, TouchActionTrackingWebView
     WebView* webView = m_webViewHelper.initializeAndLoad(m_baseURL + file, true, 0, &client);
 
     // Set size to enable hit testing, and avoid line wrapping for consistency with browser.
-    webView->resize(WebSize(700, 1000));
+    webView->resize(WebSize(800, 1200));

[gnana, 2014/02/24 18:59:50]

I changed this to fix the unit test failure for 

<div class='ta-none' style='height: 0; margin-bottom: 50px'>
  <span expected-action='none' style='display:inline-block'>
    touch-action should be inherited by inline-block elements
  </span>
</div>
error: Test point not contained in visible area

Let me know your opnion on this.

[Rick Byers, 2014/02/25 22:52:03]

Yeah, that should be fine.  At some point we may want to try to compress things
a bit to make them fit better, or split into multiple test cases.  But as long
as we have a descriptive failure like this I think we're fine. 

[gnana, 2014/02/27 13:26:59]

Done.

 
     // Scroll to verify the code properly transforms windows to client co-ords.
     const int kScrollOffset = 100;
@@ -252,14 +252,18 @@ void TouchActionTest::runTestOnTree(WebCore::ContainerNode* root, WebView* webVi
                 << "  Got element: \"" << result.innerElement()->outerHTML().stripWhiteSpace().left(80).ascii().data() << "\""
                 << std::endl << "Document render tree:" << std::endl << externalRepresentation(root->document().frame()).utf8().data();
 
+            WebCore::HitTestResult taResult = frame->eventHandler().hitTestResultAtPoint(docPoint, WebCore::HitTestRequest::ReadOnly | WebCore::HitTestRequest::Active | WebCore::HitTestRequest::TouchAction);
+
             // Now send the touch event and check any touch action result.
             sendTouchEvent(webView, WebInputEvent::TouchStart, clientPoint);
 
             AtomicString expectedAction = element->getAttribute("expected-action");
             if (expectedAction == "auto") {
-                // Auto is the default - no action set.
-                EXPECT_EQ(0, client.touchActionSetCount()) << failureContextPos;
-                EXPECT_EQ(WebTouchActionAuto, client.lastTouchAction()) << failureContextPos;
+                if (taResult.innerElement() == result.innerElement()) {

[gnana, 2014/02/24 18:59:50]

I have added this check for cases similar to this

<div class='ta-none' style='height: 0; margin-bottom: 100px'>
  <span expected-action='auto'>
    touch-action should not be inherited by inline elements
    <div expected-action='none'>But is inherited by any block descendants of
them</div>
  </span>
</div>

 the below two checks fail, because the count is set for the div and touch
action of div is none.

Please suggest me how i can fix it in better way.

[Rick Byers, 2014/02/25 22:52:03]

Oh!  Something is wrong with the hit testing code then.  I expected the hit test
to go through the span and not consider it's parent div since it's outside it's
bounds, and so ultimately land in the body (at least that's how IE appears to
behave).  But it looks like the hit test against the parent div is still being
satisfied, even though the point is outside it's bounds.  Here's a similar test
case involving mouse events and pointer-events:none:
http://jsbin.com/bosad/1/edit.  I would have expected clicking on the overflow
text NOT to trigger the event handler, but it does.  Perhaps this is a
pre-existing hit testing bug?  This repro is consistent with IE behavior though,
so I don't think we necessarily want to change that.

Can you debug and see where exactly in the hit testing code we're deciding that
the hit does actually reach the div?   Perhaps there's an issue in
RenderBlock::hitTestContents, maybe to do with HitTestBlockBackgrounds? (I don't
know what that's doing).  Perhaps there's just a step we can skip for
touch-action hit tests.

This is really getting at the crux of the CL here.  We don't want an object's
inline children to influence the hit test result at all (should behave the same
as if the child was display: none).  Here it still appears to be influencing the
hit test somehow.

[gnana, 2014/02/27 13:26:59]

Debugged and found that this issue caused in inlineflowbox::nodeatpoint. i
commented more details in inlineflowbox.cpp

[Rick Byers, 2014/02/27 14:53:11]

Good work!

+                    // Auto is the default - no action set.
+                    EXPECT_EQ(0, client.touchActionSetCount()) << failureContextPos;
+                    EXPECT_EQ(WebTouchActionAuto, client.lastTouchAction()) << failureContextPos;
+                }
             } else {
                 // Should have received exactly one touch action.
                 EXPECT_EQ(1, client.touchActionSetCount()) << failureContextPos;