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 <[email protected]>
  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@main): Crashes under 
RenderLayerCompositor::updateScrollingNodeForViewportConstrainedRole
    https://bugs.webkit.org/show_bug.cgi?id=248827
    rdar://102619100

    Reviewed by Alan Baradlay.

    In 253865@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/[email protected]


_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to