Ensure text nodes get an object if we're unsure that they will be collapsed

third_party/WebKit/Source/core/dom/Text.cpp

Index: third_party/WebKit/Source/core/dom/Text.cpp
diff --git a/third_party/WebKit/Source/core/dom/Text.cpp b/third_party/WebKit/Source/core/dom/Text.cpp
index 0ee207e66957876b84cb5180c3794fa65e837715..0efb8cb95186d32a05251a509e1e21f271f4e922 100644
--- a/third_party/WebKit/Source/core/dom/Text.cpp
+++ b/third_party/WebKit/Source/core/dom/Text.cpp
@@ -307,6 +307,12 @@ bool Text::textLayoutObjectIsNeeded(const ComputedStyle& style, const LayoutObje
         while (first && first->isFloatingOrOutOfFlowPositioned() && maxSiblingsToVisit--)
             first = first->nextSibling();
         if (!first || first == layoutObject() || LayoutTreeBuilderTraversal::nextSiblingLayoutObject(*this) == first) {
+            // If we're adding children to this flow our previous siblings are not in the layout tree yet so we
+            // cannot know if we will be the first child in the line and collapse away. We have to assume we need a layout object.
+            Node* firstChildNode = parent.node() ? LayoutTreeBuilderTraversal::firstChild(*parent.node()) : nullptr;

[esprehn, 2015/12/03 07:03:32]

this doesn't work if your parent is anonymous, are you sure this is right? when
is node() null?

[rhogan, 2015/12/03 19:45:32]

Right enough, I hadn't thought of that but in the cases where we're deciding
whether to add an object we never end up in textLayoutObjectIsNeeded unless the
parent object has a node so this only happens when called from
updateTextLayoutObject. I think we're right to miss out on the optimization in
such situations so I need to account for that here.
LayoutTests/fast/css/image-set-value-not-removed-crash.html manages it when
calling from updateTextLayoutObject() during editing.

+            if (first && first == layoutObject() && firstChildNode && !firstChildNode->layoutObject())

[esprehn, 2015/12/03 07:03:32]

This is saying "if we're the first in flow layout object, and there's a previous
sibling that doesn't have a layout object yet."

that'll always be true if the first child is display: none, is that correct?

[rhogan, 2015/12/03 19:45:32]

Sure, and in that situation we would create a text layout object that would get
collapsed away. The purpose here is to avoid that in the common cases. The bug
we're fixing is in the other direction - the text object isn't getting created
when it's needed.

+                return true;
+
             // Whitespace at the start of a block just goes away.  Don't even
             // make a layout object for this text.
             return false;