Correct touch rect hit-test against iframe with scrolled content

Source/core/layout/LayoutPart.cpp

 /*
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 2000 Simon Hausmann <hausmann@kde.org>
  *           (C) 2000 Stefan Schimanski (1Stein@gmx.de)
  * Copyright (C) 2004, 2005, 2006, 2009 Apple Inc. All rights reserved.
  * Copyright (C) Research In Motion Limited 2011. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
@@ skipping 166 matching lines @@
             if (result.hitTestRequest().listBased()) {
                 result.append(childFrameResult);
             } else if (isInsideChildFrame) {
                 // Force the result not to be cacheable because the parent
                 // frame should not cache this result; as it won't be notified of
                 // changes in the child.
                 childFrameResult.setCacheable(false);
                 result = childFrameResult;
             }
 
-            if (isInsideChildFrame)
-                return true;
+            // Don't trust |isInsideChildFrame|. Returns true only when the hit test
+            // point/rect is totally within the iframe, i.e. nodeAtPointOverWidget()
+            // also returns true.
+            // Use a temparory HitTestResult because we don't want to collect the
+            // iframe element itself if the hit-test rect is totally within the iframe.
+            if (isInsideChildFrame) {

[dtapuska, 2015/09/08 20:07:48]

I presume this code path isn't necessary for the non rect based hit test..
should it be avoided in that case?


Also is this also an issue for any element that is backed by a ScrollableArea?
ie; does it happen with a div with overflow scroll?

[Yufeng Shen (Slow to review), 2015/09/08 22:08:42]

done.
Yes, the same underlying issue applies also for overflow scroll div,
but the symptom gets mitigated by the fact that we do a re-hit-test
for gesture event, see here

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

The re-hit-test uses hitTestResultInFrame. So if the tap finds the wrong frame,
then the click is routed
to the wrong frame. But if the tap finds at least the correct frame but wrong
node, the click is
still routed to the right node. It is really complicated and subtle :(

+                HitTestResult pointOverWidgetResult = result;
+                bool pointOverWidget = nodeAtPointOverWidget(pointOverWidgetResult, locationInContainer, accumulatedOffset, action);
+                if (pointOverWidget)
+                    return true;
+                result = pointOverWidgetResult;
+                return false;
+            }
         }
     }
 
     return nodeAtPointOverWidget(result, locationInContainer, accumulatedOffset, action);
 }
 
 CompositingReasons LayoutPart::additionalCompositingReasons() const
 {
     if (requiresAcceleratedCompositing())
         return CompositingReasonIFrame;
@@ skipping 139 matching lines @@
     if (widget() && widget()->isFrameView()) {
         FrameView* childFrameView = toFrameView(widget());
         PaintInvalidationState childViewPaintInvalidationState(*childFrameView->layoutView(), paintInvalidationState);
         toFrameView(widget())->invalidateTreeIfNeeded(childViewPaintInvalidationState);
     }
 
     LayoutReplaced::invalidatePaintOfSubtreesIfNeeded(paintInvalidationState);
 }
 
 }