Autosize list markers.

Source/core/rendering/RenderListItem.cpp

Index: Source/core/rendering/RenderListItem.cpp
diff --git a/Source/core/rendering/RenderListItem.cpp b/Source/core/rendering/RenderListItem.cpp
index b3b57a571bae2dd74b1d3862e806c0178778b0f0..3b6b21cb02b08fd33e2504c331faf990cd082dff 100644
--- a/Source/core/rendering/RenderListItem.cpp
+++ b/Source/core/rendering/RenderListItem.cpp
@@ -27,6 +27,7 @@
 #include "HTMLNames.h"
 #include "core/dom/ElementTraversal.h"
 #include "core/html/HTMLOListElement.h"
+#include "core/rendering/FastTextAutosizer.h"
 #include "core/rendering/LayoutRectRecorder.h"
 #include "core/rendering/RenderListMarker.h"
 #include "core/rendering/RenderView.h"
@@ -316,6 +317,12 @@ void RenderListItem::layout()
 {
     ASSERT(needsLayout());
 
+    // The marker must be autosized before calling updateMarkerLocation.
+    // It cannot be done in the parent's beginLayout because it is not yet in the render tree.
+    FastTextAutosizer* textAutosizer = document().fastTextAutosizer();
+    if (textAutosizer)
+        textAutosizer->inflateListItem(this, m_marker);
+
     LayoutRectRecorder recorder(*this);
     updateMarkerLocation();
     RenderBlockFlow::layout();

[pdr., 2014/01/25 03:50:23]

This layout call updates the RenderListItem's contentLogicalWidth which the
cluster multiplier may depend on.

[skobes, 2014/01/28 03:10:30]

Hmm... this would only be an issue if the LI had a different width from the
containing OL/UL, right?  Hopefully not very common (and the consequence is just
that the marker's size is based on the latter).