Prevent markContainerChainForLayout to scheduleRelayout() if isInPerformLayout()

third_party/WebKit/Source/core/frame/FrameView.cpp

Index: third_party/WebKit/Source/core/frame/FrameView.cpp
diff --git a/third_party/WebKit/Source/core/frame/FrameView.cpp b/third_party/WebKit/Source/core/frame/FrameView.cpp
index 363f4c213acccdffeb7dd6a70c53cbff598f665d..a7250ae80329487edbc6ebefe69a945455521cb4 100644
--- a/third_party/WebKit/Source/core/frame/FrameView.cpp
+++ b/third_party/WebKit/Source/core/frame/FrameView.cpp
@@ -1781,6 +1781,7 @@ void FrameView::layoutOrthogonalWritingModeRoots()
 void FrameView::scheduleRelayout()
 {
     ASSERT(m_frame->view() == this);
+    RELEASE_ASSERT(!isInPerformLayout());

[kojii, 2016/04/22 05:29:05]

The critical error is to modify m_layoutSubtreeRootList (such as
clearLayoutSubtreeRootsAndMarkContainingBlocks()) while we're iterating it in:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
but we need to clear it after the iteration, so we can't assert in
DepthOrderedLayoutObjectList::clear().
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

RELEASE_ASSERT here is the lowest place where we can turn security issues to
crashes.

 
     if (!m_layoutSchedulingEnabled)
         return;
@@ -1803,6 +1804,7 @@ void FrameView::scheduleRelayout()
 void FrameView::scheduleRelayoutOfSubtree(LayoutObject* relayoutRoot)
 {
     ASSERT(m_frame->view() == this);
+    RELEASE_ASSERT(!isInPerformLayout());
 
     // FIXME: Should this call shouldScheduleLayout instead?
     if (!m_frame->document()->isActive())