Fix invalidity in HitTestCache with LayoutParts.

Source/core/layout/LayoutPart.cpp

Index: Source/core/layout/LayoutPart.cpp
diff --git a/Source/core/layout/LayoutPart.cpp b/Source/core/layout/LayoutPart.cpp
index 3bd9e7fbba2e5aafaf2d74491450b2ac38532fee..7e1af73aa8e6df5563484adb6402c6a193b82ba1 100644
--- a/Source/core/layout/LayoutPart.cpp
+++ b/Source/core/layout/LayoutPart.cpp
@@ -152,6 +152,12 @@ bool LayoutPart::nodeAtPointOverWidget(HitTestResult& result, const HitTestLocat
     // Check to see if we are really over the widget itself (and not just in the border/padding area).

[pdr., 2015/08/08 05:44:14]

It looks like there are three modes here:
1) hit test on border/padding
2) hit test on loading content
3) hit test on loaded content

The patch description sounds like we don't want to cache any of these. I see why
grouping 2 and 3 makes sense for simplicity but why can't we cache hits on the
border or padding?

[dtapuska, 2015/08/10 19:35:42]

Yes ideally we could cache the border or padding areas; but that seemed like
more complex code to add here for minimal gain.

     if ((inside || result.isRectBasedTest()) && !hadResult && result.innerNode() == node())
         result.setIsOverWidget(contentBoxRect().contains(result.localPoint()));
+
+    // If there was a hit on the LayoutReplaced; the child FrameView
+    // likely isn't loaded yet; so don't cache this result.

[pdr., 2015/08/08 05:44:14]

Can we replace "...the child FrameView likely isn't loaded yet" with an assert
that it hasn't loaded yet?

Can you help me understand why loading matters here? It looks like the codepath
here depends on more than loading. I wonder if we really just want prevent
content hit tests entirely, regardless of loading.

[dtapuska, 2015/08/10 19:35:42]

Effectively yes this patch prevents caching hit tests entirely if they are
inside a LayoutPart. The LayoutPart isn't told when the child widget is really
ready to do hit tests and we may cache an item incorrectly if it is anywhere
inside the LayoutPart but then the child then loads, creates its layers and then
can accept hit tests.

The other conditions of whether you allow child frame content and whether it is
visible to the hit test should be covered when checking that the hit test
request is actually the same type that is stored in the cache.

I presume I could add an assert for loading but it would effectively be all the
conditions that lead to the execution of the nodeAtPointOverWidget method; and
that doesn't seem to meaningful.

+    if (inside)
+        result.setCacheable(false);
+
     return inside;
 }