Begin tracking why layout is invalidated

Source/core/layout/LayoutBlockFlowLine.cpp

Index: Source/core/layout/LayoutBlockFlowLine.cpp
diff --git a/Source/core/layout/LayoutBlockFlowLine.cpp b/Source/core/layout/LayoutBlockFlowLine.cpp
index aa2a79e52e7b21b4307c6c768efb511789fcbe49..b564168728417011e48a7f49a2b381b9a3c46558 100644
--- a/Source/core/layout/LayoutBlockFlowLine.cpp
+++ b/Source/core/layout/LayoutBlockFlowLine.cpp
@@ -1695,7 +1695,7 @@ RootInlineBox* LayoutBlockFlow::determineStartPosition(LineLayoutState& layoutSt
     if (layoutState.isFullLayout()) {
         // If we encountered a new float and have inline children, mark ourself to force us to issue paint invalidations.
         if (layoutState.hasInlineChild() && !selfNeedsLayout()) {
-            setNeedsLayoutAndFullPaintInvalidation(MarkOnlyThis);
+            setNeedsLayoutAndFullPaintInvalidation(LayoutInvalidationReason::Unknown, MarkOnlyThis);

[esprehn, 2015/03/23 20:19:43]

This is from inside an already running layout

[pdr., 2015/03/24 03:56:18]

This should be okay. We have a similar situation with style recalcs which can
occur during style recalc.

The layout invalidations are pretty much only useful with devtools which keeps
handles to nodes for us. On the javascript side we can group the invalidations
however, but your point is a good one about having too many causes for any given
layout. I've switched the implementation in setNeedsLayout() to only record an
invalidation if it is the first call to setNeedsLayout. A web developer trying
to remove layouts of a given node may need to make several passes until all
causes are removed.

             setShouldDoFullPaintInvalidation();
         }