Fix crash when establishing an inline continuation inside a block continuation.

Source/core/rendering/RenderBlock.cpp

Index: Source/core/rendering/RenderBlock.cpp
diff --git a/Source/core/rendering/RenderBlock.cpp b/Source/core/rendering/RenderBlock.cpp
index b99b8b0cdddd720c373e4d4d5506d200e7f45fff..4a2a5a89d8a94eb121702537cf41ea916636268d 100644
--- a/Source/core/rendering/RenderBlock.cpp
+++ b/Source/core/rendering/RenderBlock.cpp
@@ -450,11 +450,21 @@ RenderBlock* RenderBlock::continuationBefore(RenderObject* beforeChild)
 void RenderBlock::addChildToContinuation(RenderObject* newChild, RenderObject* beforeChild)
 {
     RenderBlock* flow = continuationBefore(beforeChild);
-    ASSERT(!beforeChild || beforeChild->parent()->isAnonymousColumnSpanBlock() || beforeChild->parent()->isRenderBlock());

[mstensho (USE GERRIT), 2015/01/28 10:43:16]

This was probably here because someone knew that inserting stuff beside stuff
inside tables didn't work. Forgot to check that it wasn't a LayoutTable,
though...

The fix below copes with any type of parent, e.g. table rows and what not.

     RenderBoxModelObject* beforeChildParent = 0;
-    if (beforeChild)
+    if (beforeChild) {
         beforeChildParent = toRenderBoxModelObject(beforeChild->parent());
-    else {
+        // Don't attempt to insert into something that isn't a RenderBlockFlow (block

[mstensho (USE GERRIT), 2015/01/28 10:43:16]

This is an attempt at a proper fix for the bug, and this chunk of code is really
all it takes. The other fixes are just for safety and sanity.

This change makes sure to look further up in the ancestry chain (of
|beforeChild|), so that we:

1. Don't bypass the table object structure correction machinery (we're calling
addChildIgnoringContinuation(); imagine what that does on LayoutTable, for
instance)
2. Insert it at the right place. We'll now drill down to the right ancestor, and
even insert anonymous table objects if that's required for the new child.

+        // container). While the DOM nodes of |beforeChild| and |newChild| are siblings, there may
+        // be anonymous table wrapper objects around |beforeChild| on the layout side. Therefore,
+        // find the nearest RenderBlockFlow. If it turns out that the new renderer doesn't belong
+        // inside the anonymous table, this will make sure that it's really put on the outside. If
+        // it turns out that it does belong inside it, the normal child insertion machinery will
+        // make sure it ends up there, and at the right place too. We cannot just guess that it's
+        // going to be right under the parent of |beforeChild|.
+        while (beforeChildParent && !beforeChildParent->isRenderBlockFlow())

[Julien - ping for review, 2015/01/28 17:29:53]

This code can go past |this| while walking up the tree, not sure if it's of any
significance.

[mstensho (USE GERRIT), 2015/01/28 17:51:26]

Yeah, I added an assert against that in the second patch set.

+            beforeChildParent = toRenderBoxModelObject(beforeChildParent->parent());

[mstensho (USE GERRIT), 2015/01/28 10:43:16]

Could add some assertions here, but I'll wait and see what you guys think of the
general direction first.

+        ASSERT(beforeChildParent);

[Julien - ping for review, 2015/01/28 17:29:53]

I don't know how:

beforeChildParent->addChildIgnoringContinuation(newChild, beforeChild);

is correct knowing that |beforeChildParent| is not the direct parent of
|beforeChild| but an ancestor now.

[mstensho (USE GERRIT), 2015/01/28 17:51:26]

One of the first things RenderBlock::addChildIgnoringAnonymousColumnBlocks()
does is to do stuff if |beforeChildParent| isn't a direct child, so this should
be fine.

[Julien - ping for review, 2015/01/29 10:28:31]

Acknowledged.

+    } else {
         RenderBoxModelObject* cont = flow->continuation();
         if (cont)
             beforeChildParent = cont;