Title: [218536] releases/WebKitGTK/webkit-2.16/Source/WebCore
- Revision
- 218536
- Author
- carlo...@webkit.org
- Date
- 2017-06-19 23:14:07 -0700 (Mon, 19 Jun 2017)
Log Message
Merge r217286 - ASSERTION FAILED: !renderer().view().needsLayout() while running media/video-main-content-autoplay.html
https://bugs.webkit.org/show_bug.cgi?id=172476
Reviewed by Simon Fraser.
This patch decouples the layout call logic from the post layout task timer setup.
Just because we are switching over to asynchronous performPostLayoutTasks() it should not stop us from
running layout on a dirty tree (we could encounter a forced layout (which sets m_postLayoutTasksTimer active)
and a subsequent tree mutation during performPostLayoutTasks()).
There are a few different ways to end up here:
root layout is done -> call performPostLayoutTasks() synchronously ->
1. tree stays clean -> no action needed.
2. tree gets dirty -> setup performPostLayoutTasks timer -> run nested layout -> since m_postLayoutTasksTimer is active()
we don't try to run performPostLayoutTasks() while in the nested layout and we return with a clean tree.
* page/FrameView.cpp:
(WebCore::FrameView::layout):
Modified Paths
Diff
Modified: releases/WebKitGTK/webkit-2.16/Source/WebCore/ChangeLog (218535 => 218536)
--- releases/WebKitGTK/webkit-2.16/Source/WebCore/ChangeLog 2017-06-20 06:06:16 UTC (rev 218535)
+++ releases/WebKitGTK/webkit-2.16/Source/WebCore/ChangeLog 2017-06-20 06:14:07 UTC (rev 218536)
@@ -1,3 +1,24 @@
+2017-05-23 Zalan Bujtas <za...@apple.com>
+
+ ASSERTION FAILED: !renderer().view().needsLayout() while running media/video-main-content-autoplay.html
+ https://bugs.webkit.org/show_bug.cgi?id=172476
+
+ Reviewed by Simon Fraser.
+
+ This patch decouples the layout call logic from the post layout task timer setup.
+ Just because we are switching over to asynchronous performPostLayoutTasks() it should not stop us from
+ running layout on a dirty tree (we could encounter a forced layout (which sets m_postLayoutTasksTimer active)
+ and a subsequent tree mutation during performPostLayoutTasks()).
+
+ There are a few different ways to end up here:
+ root layout is done -> call performPostLayoutTasks() synchronously ->
+ 1. tree stays clean -> no action needed.
+ 2. tree gets dirty -> setup performPostLayoutTasks timer -> run nested layout -> since m_postLayoutTasksTimer is active()
+ we don't try to run performPostLayoutTasks() while in the nested layout and we return with a clean tree.
+
+ * page/FrameView.cpp:
+ (WebCore::FrameView::layout):
+
2017-03-24 Brent Fulgham <bfulg...@apple.com>
Handle recursive calls to ProcessingInstruction::checkStyleSheet
Modified: releases/WebKitGTK/webkit-2.16/Source/WebCore/page/FrameView.cpp (218535 => 218536)
--- releases/WebKitGTK/webkit-2.16/Source/WebCore/page/FrameView.cpp 2017-06-20 06:06:16 UTC (rev 218535)
+++ releases/WebKitGTK/webkit-2.16/Source/WebCore/page/FrameView.cpp 2017-06-20 06:14:07 UTC (rev 218536)
@@ -1575,9 +1575,9 @@
// can make us need to update again, and we can get stuck in a nasty cycle unless
// we call it through the timer here.
m_postLayoutTasksTimer.startOneShot(0);
- if (needsLayout())
- layout();
}
+ if (needsLayout())
+ layout();
}
InspectorInstrumentation::didLayout(cookie, *root);
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
