Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: ac10daa79e26b4f062cb2c1842b4787698574899 https://github.com/WebKit/WebKit/commit/ac10daa79e26b4f062cb2c1842b4787698574899 Author: Wenson Hsieh <wenson_hs...@apple.com> 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 webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes