It's possible for the style recalc timer to get scheduled after the layout timer (both delay 0). The layout timer fires first, so we do layout, but then the style recalc timer fires and we do style recalc and layout again. This happens in fast/canvas/webgl/arraybuffer-transfer-of-control.html and likely other content.
Fixing this does reduce the number of layouts slightly, but not the total time spent in layout.
Created attachment 247613 [details] Patch
Comment on attachment 247613 [details] Patch r=me This does indeed seem totally reasonable.
Comment on attachment 247613 [details] Patch Clearing flags on attachment: 247613 Committed r180846: <http://trac.webkit.org/changeset/180846>
All reviewed patches have been landed. Closing bug.
Re-opened since this is blocked by bug 142368
Fix for the regression: diff --git a/Source/WebCore/page/FrameView.cpp b/Source/WebCore/page/FrameView.cpp index 229c8a910a042486c9991e4785d8a8dd8058d711..484d90ca1f002b43c55abdb76ea17d65b9f395a2 100644 --- a/Source/WebCore/page/FrameView.cpp +++ b/Source/WebCore/page/FrameView.cpp @@ -2440,6 +2440,12 @@ void FrameView::layoutTimerFired() if (!frame().document()->ownerElement()) printf("Layout timer fired at %lld\n", frame().document()->elapsedTime().count()); #endif + + { + TemporaryChange<bool> layoutSchedulingDisabler(m_layoutSchedulingEnabled, false); + frame().document()->updateStyleIfNeeded(); + } + layout(); } Needs testcase.