Fix paint invalidation for composited vertical-rl having overflow

third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp

Index: third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp
diff --git a/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp b/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp
index d61e401ef28ecdcfb032ea4fa85d80dd354f6b01..192eb2a5a59bb0180e93b1f43708b3f9b21e828f 100644
--- a/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp
+++ b/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp
@@ -418,11 +418,8 @@ static void slowMapToVisualRectInAncestorSpace(const LayoutObject& object, const
     // TODO(wkorman): The flip below is required because visual rects are
     // currently in "physical coordinates with flipped block-flow direction"
     // (see LayoutBoxModelObject.h) but we need them to be in physical
-    // coordinates. When we're mapping within exactly one object we keep the
-    // input rect flipped because we'd just have to re-flip in short order, as
-    // the output of this method must be in the "physical coordinates with
-    // flipped block-flow direction.
-    if (object.isBox() && object != ancestor)

[chrishtr, 2016/09/27 00:02:43]

Is there an existing test that this is not needed for boxes that are not
LayoutViews? I agree with your 
logical argument, but we did debug for a while and concluded this was correct...
:(

[Xianzhu, 2016/09/27 00:26:45]

There seems no existing test. The added test
paint/invalidation/composited-vertical-rl-overflow.html can reproduce the bug.
The key is unsymmetrical left and right overflows.

I also didn't notice the issue when the the above code was added. Just noticed
it when I was trying to fix the flipping issue for slimmingPaintInvalidation on
spv1. 

+    // coordinates.
+    if (object.isBox())
         toLayoutBox(&object)->flipForWritingMode(rect);
 
     if (object.isLayoutView())