Title: [207941] releases/WebKitGTK/webkit-2.14/Source/WebCore
- Revision
- 207941
- Author
- [email protected]
- Date
- 2016-10-26 23:40:26 -0700 (Wed, 26 Oct 2016)
Log Message
Merge r206765 - [ListItems] Render tree should be all clean by the end of FrameView::layout().
https://bugs.webkit.org/show_bug.cgi?id=162832
Reviewed by Simon Fraser.
List item markers are inserted into the tree during layout, right before laying out
the list item (that's a big FIXME). At this point we already know what part of the tree
needs to be laid out. Inserting a list item marker does not expand this dirty area.
However whenever we insert a new renderer into the tree, we call setNeedsLayout on the contining block chain.
In certain cases (floating renderers), it could potentially trigger some unintentional markings
and we return from FrameView::layout() with a dirty subtree.
This patch preemptively marks the list item and its marker dirty so that
when the marker is getting inserted into the tree, we stop the marking at the parent.
Not testable.
* rendering/RenderListItem.cpp:
(WebCore::RenderListItem::insertOrMoveMarkerRendererIfNeeded):
Modified Paths
Diff
Modified: releases/WebKitGTK/webkit-2.14/Source/WebCore/ChangeLog (207940 => 207941)
--- releases/WebKitGTK/webkit-2.14/Source/WebCore/ChangeLog 2016-10-27 06:37:25 UTC (rev 207940)
+++ releases/WebKitGTK/webkit-2.14/Source/WebCore/ChangeLog 2016-10-27 06:40:26 UTC (rev 207941)
@@ -1,3 +1,25 @@
+2016-10-03 Zalan Bujtas <[email protected]>
+
+ [ListItems] Render tree should be all clean by the end of FrameView::layout().
+ https://bugs.webkit.org/show_bug.cgi?id=162832
+
+ Reviewed by Simon Fraser.
+
+ List item markers are inserted into the tree during layout, right before laying out
+ the list item (that's a big FIXME). At this point we already know what part of the tree
+ needs to be laid out. Inserting a list item marker does not expand this dirty area.
+ However whenever we insert a new renderer into the tree, we call setNeedsLayout on the contining block chain.
+ In certain cases (floating renderers), it could potentially trigger some unintentional markings
+ and we return from FrameView::layout() with a dirty subtree.
+
+ This patch preemptively marks the list item and its marker dirty so that
+ when the marker is getting inserted into the tree, we stop the marking at the parent.
+
+ Not testable.
+
+ * rendering/RenderListItem.cpp:
+ (WebCore::RenderListItem::insertOrMoveMarkerRendererIfNeeded):
+
2016-10-04 Carlos Garcia Campos <[email protected]>
[SOUP] Remove SSLPolicyFlags from SoupNetworkSession
Modified: releases/WebKitGTK/webkit-2.14/Source/WebCore/rendering/RenderListItem.cpp (207940 => 207941)
--- releases/WebKitGTK/webkit-2.14/Source/WebCore/rendering/RenderListItem.cpp 2016-10-27 06:37:25 UTC (rev 207940)
+++ releases/WebKitGTK/webkit-2.14/Source/WebCore/rendering/RenderListItem.cpp 2016-10-27 06:40:26 UTC (rev 207941)
@@ -287,6 +287,11 @@
// Removing and adding the marker can trigger repainting in
// containers other than ourselves, so we need to disable LayoutState.
LayoutStateDisabler layoutStateDisabler(view());
+ // Mark the parent dirty so that when the marker gets inserted into the tree
+ // and dirties ancestors, it stops at the parent.
+ newParent->setChildNeedsLayout(MarkOnlyThis);
+ m_marker->setNeedsLayout(MarkOnlyThis);
+
m_marker->removeFromParent();
newParent->addChild(m_marker, firstNonMarkerChild(*newParent));
m_marker->updateMarginsAndContent();
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
