Bug 141688 – FrameView::layoutTimerFired() should update style if needed before doing layout

• Component: Layout and Rendering
• Status: REOPENED

[Simon Fraser (smfr)]

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.

[Simon Fraser (smfr)]

Fixing this does reduce the number of layouts slightly, but not the total time spent in layout.

[Simon Fraser (smfr)]

Created attachment 247613 [details]
Patch

[Andreas Kling]

Comment on attachment 247613 [details]
Patch

r=me
This does indeed seem totally reasonable.

[WebKit Commit Bot]

Comment on attachment 247613 [details]
Patch

Clearing flags on attachment: 247613

Committed r180846: <http://trac.webkit.org/changeset/180846>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 142368

[Simon Fraser (smfr)]

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.