[webkit-changes] [WebKit/WebKit] 4b14aa: Cherry-pick df0e5116081b. rdar://problem/102619100
Simon Fraser
noreply at github.com
Fri Dec 9 11:12:55 PST 2022
Branch: refs/heads/safari-7615.1.14-branch
Home: https://github.com/WebKit/WebKit
Commit: 4b14aa234bb74a84c91adef0e7b5500172633901
https://github.com/WebKit/WebKit/commit/4b14aa234bb74a84c91adef0e7b5500172633901
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2022-12-09 (Fri, 09 Dec 2022)
Changed paths:
A LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor-expected.txt
A LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp
Log Message:
-----------
Cherry-pick df0e5116081b. rdar://problem/102619100
REGRESSION (253865 at main): Crashes under RenderLayerCompositor::updateScrollingNodeForViewportConstrainedRole
https://bugs.webkit.org/show_bug.cgi?id=248827
rdar://102619100
Reviewed by Alan Baradlay.
In 253865 at main I introduced `m_viewportAnchorLayer`, which is used by the scrolling tree
to move fixed and sticky position layers. However, this revealed bugs in the compositing
dirty state management in the RenderLayer tree, where some types of tree mutations would
fail to trigger the "configuration" compositing update on a composited layer which is
responsible for the addition/removal of the `m_viewportAnchorLayer`.
From the collection of crash reports, I diagnosed two scenarios:
On google.com, when selecting results in the map view (rdar://102713246), a fixed layer
gained/lost a transformed ancestor. Transforms act as containing block for fixed, so
this changes whether the fixed layer is viewport-constrained. Fixed by having
`RenderLayer::setBehavesAsFixed()` call `setNeedsCompositingConfigurationUpdate()` on
fixed layers. Normally repaints trigger `setNeedsCompositingConfigurationUpdate()`; I
was not able to creation a reduction for this (the google page has nested fixed and
`visibility:hidden`, which may contribute).
The second scenario involved a sticky position layer which gains/loses an
async-scrollable ancestor. Fixed by having
`RenderLayerScrollableArea::computeHasCompositedScrollableOverflow()` call
`setDescendantsNeedUpdateBackingAndHierarchyTraversal()` on the stacking context
ancestor. Tested by sticky-gain-composited-scrolling-ancestor.html.
Also defensively early return in `computeFixedViewportConstraints()` and
`computeStickyViewportConstraints()` if the anchor layer is null.
* LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor-expected.txt: Added.
* LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::recursiveUpdateLayerPositions):
(WebCore::RenderLayer::setBehavesAsFixed):
* Source/WebCore/rendering/RenderLayer.h:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeFixedViewportConstraints const):
(WebCore::RenderLayerCompositor::computeStickyViewportConstraints const):
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::RenderLayerScrollableArea::computeHasCompositedScrollableOverflow):
Canonical link: https://commits.webkit.org/257455@main
Canonical link: https://commits.webkit.org/257350.11@safari-7615.1.14-branch
More information about the webkit-changes
mailing list