Made ElementRareData store ComputedStyle on LayoutObject if possible.

third_party/WebKit/Source/core/dom/ElementRareData.h

Index: third_party/WebKit/Source/core/dom/ElementRareData.h
diff --git a/third_party/WebKit/Source/core/dom/ElementRareData.h b/third_party/WebKit/Source/core/dom/ElementRareData.h
index fe196fb89ed539bba4cafc5fc5375e87f58407c6..96c1c9dca4be1052fdee87c31cfc657ee67a9129 100644
--- a/third_party/WebKit/Source/core/dom/ElementRareData.h
+++ b/third_party/WebKit/Source/core/dom/ElementRareData.h
@@ -91,9 +91,25 @@ public:
     NamedNodeMap* attributeMap() const { return m_attributeMap.get(); }
     void setAttributeMap(NamedNodeMap* attributeMap) { m_attributeMap = attributeMap; }
 
-    ComputedStyle* computedStyle() const { return m_computedStyle.get(); }
-    void setComputedStyle(PassRefPtr<ComputedStyle> computedStyle) { m_computedStyle = computedStyle; }
-    void clearComputedStyle() { m_computedStyle = nullptr; }
+    ComputedStyle* computedStyle() const
+    {
+        DCHECK(!(layoutObject() && m_computedStyle));
+        if (layoutObject())
+            return layoutObject()->mutableStyle();
+        return m_computedStyle.get();
+    }
+    void setComputedStyle(PassRefPtr<ComputedStyle> computedStyle)
+    {
+        if (layoutObject())
+            layoutObject()->setStyleInternal(computedStyle);

[esprehn, 2016/09/24 02:10:52]

This case isn't reachable (outside your test which doesn't look right), you
can't end up inside ElementRareData::setComputedStyle when there's a
layoutObject. That code is only reached from Element::ensureComputedStyle

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Eleme...

when mutableComputedStyle was null, which can only happen if layoutObject() was
null, since layout objects always have a style except very briefly inside
LayoutTreeBuilder between the create call and the setStyle call (we could probs
fix that by passing the style into the constructor, WebKit did it a while ago,
then LayoutObject::style could return a reference).

Note also that using setStyleInternal here is bad since it potentially stuffs an
invalid style into a layout object. This patch worked because the code was
unreachable. setStyleInternal exists for dealing with some complex style sharing
situations. It's also gotten used in a few other cases, but they're super
subtle. Generally speaking you should never use setStyleInternal unless the
newStyle you're setting would return true from ComputedStyle::operator== (which
is expensive, so you don't want to check that yourself outside the recalc
phase).

I know there's a few other callers, like the TextAutosizer. Its usage of
setStyleInternal is technically correct, even though it violates the operator==
requirement, because of how it works inside layout updating styles recursively
down the tree, but I'll admit it's not obvious.

+        else
+            m_computedStyle = computedStyle;
+    }
+    void clearComputedStyleIfNoLayoutObject()
+    {
+        DCHECK(!(layoutObject() && m_computedStyle));

[esprehn, 2016/09/24 02:10:52]

Plz run demorgans :D running it in my head is hard, this check is:

DCHECK(!layoutObject() || !m_computedStyle)

so we can end up in here when there's a layoutObject as long as m_computedStyle
was already null. That's apparent inside Element::recalcStyle where we call this
totally ignoring the state of if there's a layout object.

I'd remove the long IfNoLayoutObject thing here and just leave this as
clearComputedStyle(). This method shouldn't need to care about if there's a
layout object.

+        m_computedStyle = nullptr;
+    }
 
     ClassList* classList() const { return m_classList.get(); }
     void setClassList(ClassList* classList) { m_classList = classList; }