Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0a76e9fdb00067249467a11dba3dcf4adb806de6
https://github.com/WebKit/WebKit/commit/0a76e9fdb00067249467a11dba3dcf4adb806de6
Author: Wenson Hsieh <[email protected]>
Date: 2025-10-30 (Thu, 30 Oct 2025)
Changed paths:
M Source/WebCore/page/LocalFrameView.cpp
M Source/WebCore/page/LocalFrameView.h
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
M Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingStateNode.h
M Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.h
M
Source/WebCore/page/scrolling/coordinated/ScrollingTreeFrameScrollingNodeCoordinated.cpp
M Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerCompositor.h
M
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.serialization.in
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Tools/TestWebKitAPI/Tests/WebKit/WKThumbnailView.mm
Log Message:
-----------
[macOS 26]
imported/w3c/web-platform-tests/css/css-view-transitions/new-content-has-scrollbars.html
fails with an image diff
https://bugs.webkit.org/show_bug.cgi?id=300329
rdar://161369380
Reviewed by Abrar Rahman Protyasha.
On macOS Tahoe, the background of system scrollbars are now fully transparent;
previously, they were
opaque. Furthermore, there exists a long-standing bug where the clipping layer
height extends below
the viewport, when the page is scrolled to the top with a non-zero top content
inset.
When always-on scrollbars are enabled, this WPT fails in Tahoe because the ref
page no longer shows
a pink background in the horizontal scrollbar near the bottom of the viewport;
instead, the page
behind the scrollbar shows through (revealing the green/black checkerboard
pattern underneath).
To fix this, we realign the test and ref by making sure the frame clipping rect
height does **not**
extend below the viewport, in the case where part of the top content inset area
above the page is
visible (i.e. the user is scrolled near the top of the page). To achieve that,
we dynamically shrink
the height of the frame clipping rect such that the clipping layer y offset
(i.e. the top content
inset amount when scrolled to the very top of the page) is subtracted from the
height of the
clipping layer, when the top content inset area is (at least) partially visible.
See below for more details.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::insetClipLayerRect):
Adjust the size of the clipping layer depending on its position, such that it
shrinks when scrolled
into the top content inset area (i.e. when it intersects with the top content
inset area), and
expands to the full `sizeForVisibleContent` after scrolling down.
Note that we only apply this adjustment to the y-axis for now, since:
1. That alone is sufficient to address this WPT failure.
2. On the x-axis, we'd need a bit more refactoring to correctly account for
`insetForLeftScrollbarSpace()` in the case where `scrollbar-gutter` is
stable on both edges.
(WebCore::LocalFrameView::positionForInsetClipLayer): Deleted.
Rename `positionForInsetClipLayer` to `insetClipLayerRect`, and make it return
a rect representing
both the position and size of the inset clip layer. If the top content inset
area is visible, we
additionally shrink the height of the inset clip layer, such that the bottom
edge of the layer
remains within the visible area.
* Source/WebCore/page/LocalFrameView.h:
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::reconcileScrollingState):
(WebCore::AsyncScrollingCoordinator::setFrameScrollingNodeState):
Plumb `sizeForVisibleContent` to the UI process via frame scrolling nodes in
the scrolling tree, so
that we can mirror adjustments to the size of the clipping layer in the UI
process. Importantly,
note that this size honors `scrollbar-gutter`.
* Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.cpp:
(WebCore::ScrollingStateFrameScrollingNode::ScrollingStateFrameScrollingNode):
(WebCore::ScrollingStateFrameScrollingNode::applicableProperties const):
(WebCore::ScrollingStateFrameScrollingNode::setSizeForVisibleContent):
(WebCore::ScrollingStateFrameScrollingNode::dumpProperties const):
* Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h:
* Source/WebCore/page/scrolling/ScrollingStateNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.cpp:
(WebCore::ScrollingTreeFrameScrollingNode::commitStateBeforeChildren):
(WebCore::ScrollingTreeFrameScrollingNode::dumpProperties const):
* Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.h:
* Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm:
(WebCore::ScrollingTreeFrameScrollingNodeMac::repositionRelatedLayers):
Change this to call `insetClipLayerRect`. This allows us to make sure the
UI-side scrolling tree
logic resizes the clipping layer while scrolling, when the top content inset
area is visible.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateScrollLayerClipping):
Change this to call `insetClipLayerRect`, to grab both the inset clipping
layer's computed position
and size.
(WebCore::RenderLayerCompositor::insetClipLayerRect const):
Add a helper method to compute the current `insetClipLayerRect`, by passing
relevant state into
`LocalFrameView::insetClipLayerRect`. Renamed from `positionForClipLayer` (and
refactored to return
the current visible size as well, as a part of a single rect).
(WebCore::RenderLayerCompositor::ensureRootLayer):
(WebCore::RenderLayerCompositor::positionForClipLayer const): Deleted.
Changed to `insetClipLayerRect`. See above.
* Source/WebCore/rendering/RenderLayerCompositor.h:
*
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.serialization.in:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Plumb `sizeForVisibleContent` through the scrolling tree. See above.
* Tools/TestWebKitAPI/Tests/WebKit/WKThumbnailView.mm:
(TestWebKitAPI::leftCornerColorsForThumbnailView):
Adjust an existing API test which was relying on the fact that the clip layer
extended below the
viewport, such that it samples the snapshot pixel color at coordinates that are
visible to the user.
I manually verified that the original bug in rdar://107843180 does not
reproduce after this patch,
by pinching out on macOS with `-[_WKThumbnailView _didTakeSnapshot:]` commented
out, and verifying
that we don't end up with a top-content-inset-sized jump while entering visual
tab picker.
Canonical link: https://commits.webkit.org/302370@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
