[New Multicolumn] Actual support for layout of column-span:all.

Source/core/rendering/RenderObject.cpp

Index: Source/core/rendering/RenderObject.cpp
diff --git a/Source/core/rendering/RenderObject.cpp b/Source/core/rendering/RenderObject.cpp
index ed9585fe0f2c3cdeaff5780f28c637af60d38eae..d3f43f044dc394c6e4c5ef4ce771aa30d110dee7 100644
--- a/Source/core/rendering/RenderObject.cpp
+++ b/Source/core/rendering/RenderObject.cpp
@@ -57,7 +57,6 @@
 #include "core/rendering/RenderCounter.h"
 #include "core/rendering/RenderDeprecatedFlexibleBox.h"
 #include "core/rendering/RenderFlexibleBox.h"
-#include "core/rendering/RenderFlowThread.h"
 #include "core/rendering/RenderGeometryMap.h"
 #include "core/rendering/RenderGrid.h"
 #include "core/rendering/RenderImage.h"
@@ -65,6 +64,7 @@
 #include "core/rendering/RenderInline.h"
 #include "core/rendering/RenderLayer.h"
 #include "core/rendering/RenderListItem.h"
+#include "core/rendering/RenderMultiColumnFlowThread.h"
 #include "core/rendering/RenderObjectInlines.h"
 #include "core/rendering/RenderPart.h"
 #include "core/rendering/RenderScrollbarPart.h"
@@ -325,6 +325,13 @@ bool RenderObject::requiresAnonymousTableWrappers(const RenderObject* newChild)
     return false;
 }
 
+bool RenderObject::isValidColumnSpanAll() const
+{
+    ASSERT(style()->columnSpan() == ColumnSpanAll);
+    RenderFlowThread* flowThread = flowThreadContainingBlock();
+    return flowThread && flowThread->isColumnSpanner(this);
+}
+
 void RenderObject::addChild(RenderObject* newChild, RenderObject* beforeChild)
 {
     ASSERT(isAllowedToModifyRenderTreeStructure(document()));
@@ -634,7 +641,7 @@ RenderFlowThread* RenderObject::locateFlowThreadContainingBlock() const
     while (curr) {
         if (curr->isRenderFlowThread())
             return toRenderFlowThread(curr);
-        curr = curr->containingBlock();
+        curr = curr->container();

[Julien - ping for review, 2014/11/19 17:54:34]

Is this really correct? The main difference between containingBlock() and
container() is relative positioned inlines, which you shouldn't impact
multi-column.

[mstensho (USE GERRIT), 2014/11/21 15:39:24]

Now that containingBlock() may end up calling this method (because of spanner
awareness), I cannot call containingBlock() from here, or we'd get an infinite
recursion. :( This is why I went for the ugly stuff in RenderBox.cpp, that your
review comment had me revert.

So, what to do?

A: Introduce a parameter to containingBlock, that can be used to ignore special
treatment for spanners.
B: Split containingBlock() into pieces, so that we can easily jump to containing
blocks for abspos and fixedpos here.
C: duplicate as much as we need from containingBlock() here.

I went for B, because it seemed like the least ugly option (but admittedly the
big winner in terms of the number of changed code lines). I uploaded this as a
separate patch set. I kept using the beautiful variable 'o' for RenderObject*
here and there, mainly to minimize the diff, but maybe we could come up with
something longer?

     }
     return 0;
 }
@@ -834,6 +841,8 @@ RenderBlock* RenderObject::containingBlock() const
 
         while (o && o->isAnonymousBlock())
             o = o->containingBlock();
+    } else if (isColumnSpanAll()) {
+        o = toRenderMultiColumnFlowThread(flowThreadContainingBlock())->multiColumnBlockFlow();

[Julien - ping for review, 2014/11/19 17:54:34]

If you update containingBlock(), you should also update container().

[mstensho (USE GERRIT), 2014/11/21 15:39:24]

If I do that, I also have to deal with changed behavior in
RenderObject::markContainingBlocksForLayout(), which means that I'll have to
change how we get to the spanners during layout, since we won't necessarily
reach the parent RenderBlock of spanners anymore. By all means, this may turn
out to be a good and beautiful thing, but it will be a rather fundamental change
in this CL.

But I feel that I've already changed the code too much since last time you gave
feedback, so I won't do this until you've had a look at what I've done so far.
You might ask me to go back to doing a couple of ugly things with
RenderBox::containingBlockLogical{Width,Height}ForContent() instead. :)

Let me know if you still want me to patch container().

[mstensho (USE GERRIT), 2014/12/10 13:48:19]

To follow up here: I tried this (make container() tell the truth, i.e. return
the multicol container as containing block for spanners). This has vast
consequences for the code, as expected, and kind of forces us to truly take
spanners out from the flow thread (pretty much similar to what we do for
absolutely positioned elements in general). I really liked the result, but I've
created new CLs for it (see top of comment). If you like them, we can drop this
CL.

     } else {
         while (o && ((o->isInline() && !o->isReplaced()) || !o->isRenderBlock()))
             o = o->parent();
@@ -2418,6 +2427,9 @@ void RenderObject::removeFromRenderFlowThreadRecursive(RenderFlowThread* renderF
         for (RenderObject* child = children->firstChild(); child; child = child->nextSibling())
             child->removeFromRenderFlowThreadRecursive(renderFlowThread);
     }
+
+    if (renderFlowThread && renderFlowThread != this)
+        renderFlowThread->flowThreadDescendantWillBeRemoved(this);
     setFlowThreadState(NotInsideFlowThread);
 }