[webkit-changes] [WebKit/WebKit] ac10da: REGRESSION (263722 at main): Unable to scroll languag...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ac10daa79e26b4f062cb2c1842b4787698574899
      https://github.com/WebKit/WebKit/commit/ac10daa79e26b4f062cb2c1842b4787698574899
  Author: Wenson Hsieh <wenson_hsieh at 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 at 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 at 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