Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ac10daa79e26b4f062cb2c1842b4787698574899
https://github.com/WebKit/WebKit/commit/ac10daa79e26b4f062cb2c1842b4787698574899
Author: Wenson Hsieh <[email protected]>
Date: 2023-06-29 (Thu, 29 Jun 2023)
Changed paths:
A
LayoutTests/fast/scrolling/ios/overflow-scroll-after-visibility-change-expected.txt
A
LayoutTests/fast/scrolling/ios/overflow-scroll-after-visibility-change.html
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
REGRESSION (263722@main): Unable to scroll language picker on etrade.com
https://bugs.webkit.org/show_bug.cgi?id=258433
rdar://109613133
Reviewed by Simon Fraser.
After the changes in 263722@main, certain overflow scrolling containers on
etrade.com are no longer
scrollable via pan gesture or mouse wheel on iOS; this is because we fail to
create corresponding
native child scroll views corresponding to these regions in the view hierarchy,
which in turn is
because we never end up setting `m_hasCompositedScrollableOverflow` to `true`
inside of
`RenderLayerScrollableArea::computeHasCompositedScrollableOverflow()`, despite
the fact that we have
vertical scrollable overflow and we can use composited scrolling.
The overflow scrolling container in question is shown by removing `visibility:
hidden;` on an
ancestor of these containers, which currently triggers only a style update
(calling into the above
method with `LayoutUpToDate::No`) with no subsequent layout update, causing
`m_hasCompositedScrollableOverflow` to remain `false`.
To address this, we make an adjustment in `RenderLayer::styleChanged` to pass
`LayoutUpToDate::Yes`
into `computeHasCompositedScrollableOverflow`, in the case where the style
difference only triggers
at most a layer repaint (or recomposite). In the case where we're only issuing
a repaint as a result
of the style change (e.g. when toggling visibility), the overflow amount isn't
going to change, so
it's safe to compute `m_hasCompositedScrollableOverflow` then and there.
However, in the case where
the style difference is going to trigger layout, it's safe to just run the
computation using
`LayoutUpToDate::No`, since we'll eventually recompute it with
`LayoutUpToDate::Yes` after we finish
performing layout.
*
LayoutTests/fast/scrolling/ios/overflow-scroll-after-visibility-change-expected.txt:
Added.
* LayoutTests/fast/scrolling/ios/overflow-scroll-after-visibility-change.html:
Added.
Add a layout test to verify that we propagate overflow scrolling regions via
scrolling state tree to
the UI process in this scenario, after toggling `visibility` to `visible`.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects const):
Canonical link: https://commits.webkit.org/265624@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
