Support edge-inclusive intersections in mapToVisibleRectInAncestorSpace

third_party/WebKit/Source/core/layout/LayoutObject.h

Index: third_party/WebKit/Source/core/layout/LayoutObject.h
diff --git a/third_party/WebKit/Source/core/layout/LayoutObject.h b/third_party/WebKit/Source/core/layout/LayoutObject.h
index 387058354128dc2e7c11ef76bba0ec84dd51844c..af16a97c2613176f035bee6762f268af37c4f6fd 100644
--- a/third_party/WebKit/Source/core/layout/LayoutObject.h
+++ b/third_party/WebKit/Source/core/layout/LayoutObject.h
@@ -1148,7 +1148,10 @@ public:
     // Given a rect in the object's coordinate space, compute a rect in the coordinate space of |ancestor|.  If
     // intermediate containers have clipping or scrolling of any kind, it is applied; but overflow clipping is *not*
     // applied for |ancestor| itself. The output rect is suitable for purposes such as paint invalidation.
-    virtual void mapToVisibleRectInAncestorSpace(const LayoutBoxModelObject* ancestor, LayoutRect&, const PaintInvalidationState*) const;
+    // The return value indicates whether the output rect actually has a visible intersection
+    // with the ancestor.  If edgeInclusive is true, the return value can be true even if the
+    // resulting rect is zero-area.
+    virtual bool mapToVisibleRectInAncestorSpace(const LayoutBoxModelObject* ancestor, LayoutRect&, const PaintInvalidationState*, bool edgeInclusive) const;

[eae, 2016/03/22 00:13:50]

Adding a second capability (intersection detection) to a translation method
seems really odd to me and I don't understand why that is needed. Shouldn't the
intersection check be done on the resulting rects _after_ translation?

[szager1, 2016/03/22 00:55:48]

One of the core features of this method is that it applies clipping up the
hierarchy, but prior to this patch the clipping was not edge-aware, as required
by IntersectionObserver.  Adding a flag and a bool return value was the least
intrusive way I could think of to add that capability.

[eae, 2016/03/22 17:54:15]

Oh, I see. Didn't realize it did clipping until I start digging into the code
this morning. We might want to rename mapToVisibleRectInAncestorSpace to include
the word clipping (in a subsequent patch, not as a part of this one).

 
     // Return the offset to the column in which the specified point (in flow-thread coordinates)
     // lives. This is used to convert a flow-thread point to a visual point.