Clip abspos descendants correctly in all columns (not just the first).

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

Index: third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
diff --git a/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp b/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
index 0c7af6cbd0553824d52db1650f1c05ee4ec47012..bec27d1daef4dee160b2662a19ddab36e1465c99 100644
--- a/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
+++ b/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
@@ -941,18 +941,25 @@ void LayoutBoxModelObject::mapAbsoluteToLocalPoint(MapCoordinatesFlags mode, Tra
 
     o->mapAbsoluteToLocalPoint(mode, transformState);
 
-    LayoutSize containerOffset = offsetFromContainer(o, LayoutPoint());
+    LayoutSize containerOffset;
 
-    if (o->isLayoutFlowThread()) {
+    if (isLayoutFlowThread()) {
         // Descending into a flow thread. Convert to the local coordinate space, i.e. flow thread coordinates.
-        const LayoutFlowThread* flowThread = toLayoutFlowThread(o);
+        const LayoutFlowThread* flowThread = toLayoutFlowThread(this);
         LayoutPoint visualPoint = LayoutPoint(transformState.mappedPoint());
         transformState.move(visualPoint - flowThread->visualPointToFlowThreadPoint(visualPoint));
-        // |containerOffset| is also in visual coordinates. Convert to flow thread coordinates.
-        // TODO(mstensho): Wouldn't it be better add a parameter to instruct offsetFromContainer()
-        // to return flowthread coordinates in the first place? We're effectively performing two
-        // conversions here, when in fact none is needed.
-        containerOffset = toLayoutSize(flowThread->visualPointToFlowThreadPoint(toLayoutPoint(containerOffset)));
+        // TODO(mstensho): Get rid of this special calculation of |containerOffset|. We cannot use
+        // offsetFromContainer() at the moment, because it converts from flow thread coordinates to
+        // visual coordinates. That's a reasonable thing to do when walking *upwards* in the tree,
+        // when leaving the flow thread coordinate space and the multicol container on our way
+        // up. But when walking downwards (like here), we don't want that. So this isn't really a

[chrishtr, 2015/12/14 21:39:51]

Why is it generally not desired to adjust when walking downwards? Isn't it
well-defined
to ask that question?

Also, this fix is independent of the PaintLayerClipper one right?

[mstensho (USE GERRIT), 2016/01/05 08:55:25]

When walking downwards into a multicol container, you have visual coordinates
and ENTER a flow thread coordinate space. When walking upwards out of a multicol
container, you have flow thread coordinates and LEAVE a flow thread coordinate
space.
 
Well, this makes the code behave to PaintLayerClipper's liking. :)

But yeah, better clean up this code in separate CLs first. A new quest has begun
in https://codereview.chromium.org/1516003003/ . When everything is cleaned up,
it should be more easy to figure out how to fix this bug cleanly.

+        // conversion job best done in offsetFromContainer() (it's there just to avoid massive code
+        // duplication). It's possible to get rid of it cleanly, but it requires some refactoring
+        // of mapLocalToContainer() and its neighborhood, which is really the only place where we
+        // want the flowthread-to-visual conversion.
+        containerOffset = flowThread->topLeftLocationOffset();
+    } else {
+        containerOffset = offsetFromContainer(o, LayoutPoint());
     }
 
     bool preserve3D = mode & UseTransforms && (o->style()->preserves3D() || style()->preserves3D());