[New Multicolumn] Let a spanner's containing block be the multicol container.

Source/core/rendering/RenderBlockFlow.cpp

Index: Source/core/rendering/RenderBlockFlow.cpp
diff --git a/Source/core/rendering/RenderBlockFlow.cpp b/Source/core/rendering/RenderBlockFlow.cpp
index ace7c2d43f56633d9b8cdfd3900a51c68c072d3d..580c9b24546acd287f74bac660d43a247f1084a8 100644
--- a/Source/core/rendering/RenderBlockFlow.cpp
+++ b/Source/core/rendering/RenderBlockFlow.cpp
@@ -42,6 +42,7 @@
 #include "core/rendering/RenderFlowThread.h"
 #include "core/rendering/RenderLayer.h"
 #include "core/rendering/RenderMultiColumnFlowThread.h"
+#include "core/rendering/RenderMultiColumnSpannerPlaceholder.h"
 #include "core/rendering/RenderPagedFlowThread.h"
 #include "core/rendering/RenderText.h"
 #include "core/rendering/RenderView.h"
@@ -1057,6 +1058,11 @@ void RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, SubtreeLayoutSc
             adjustFloatingBlock(marginInfo);
             continue;
         }
+        if (child->isColumnSpanAll()) {
+            // This is not the containing block of the spanner. The spanner's placeholder will lay
+            // it out in due course.
+            continue;
+        }

[Julien - ping for review, 2014/12/11 19:09:37]

We have some code to avoid laying out some children that are "special". It's
currently used for renderers that needs some special treatment (e.g. <legend>).
Maybe we could somehow extend the layoutSpecialExcludedChild() (methinks we
could have several of these now).

Also mildly orthogonal is that it is starting to be *really* hard to know what
should and shouldn't be laid out during "normal" layout (not positioned, not
special, not column-spanner, ...) so we will want to add some child iterator.

[mstensho (USE GERRIT), 2014/12/11 21:01:14]

Then we would need to have layoutSpecialExcludedChild() return a list of
renderers, since there may be more than one spanner (even along with e.g. a
legend, if this is a fieldset). BTW: I'm planning to add some code for the
placeholders here, as you may have noticed already. So it won't be just a
"continue" eventually.
Yeah, in this sense the spanners are neither more nor less special than floats
and absposses. So I think they should be treated in similar ways in the code.
Which makes me think that for now, the spanner skipping belongs right here.

I think it's rather clean to have everything here, rather than wasting time on
building a list of excluded renderers, but in any case, I don't think changing
this should be part of this CL.

Or did you want me to change it right away?

[Julien - ping for review, 2014/12/11 23:45:44]

No, we shouldn't do it as part of this change. The pressure is just building to
think about a cleaner design around
renderers-in-the-tree-but-specially-laid-out.

 
         // Lay out the child.
         layoutBlockChild(*child, marginInfo, previousFloatLogicalBottom);
@@ -1971,6 +1977,16 @@ void RenderBlockFlow::styleDidChange(StyleDifference diff, const RenderStyle* ol
         createOrDestroyMultiColumnFlowThreadIfNeeded(oldStyle);
 }
 
+void RenderBlockFlow::updateBlockChildDirtyBitsBeforeLayout(bool relayoutChildren, RenderBox& child)
+{
+    if (child.isRenderMultiColumnSpannerPlaceholder() && toRenderMultiColumnSpannerPlaceholder(child).rendererInFlowThread()->needsLayout()) {
+        // The containing block of a spanner is the multicol container (|this| block), but the spanner
+        // is laid out via its spanner set (|child|), so we need to make sure that we enter it.
+        child.setChildNeedsLayout(MarkOnlyThis);
+    }
+    RenderBlock::updateBlockChildDirtyBitsBeforeLayout(relayoutChildren, child);
+}
+
 void RenderBlockFlow::updateStaticInlinePositionForChild(RenderBox& child, LayoutUnit logicalTop)
 {
     if (child.style()->isOriginalDisplayInlineType())