[webkit-changes] [WebKit/WebKit] 41a2db: [iOS] Stop using -[UIScrollView _isInterruptingDec...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 41a2db639391c73e7eba6df8c136705c213b1276
      https://github.com/WebKit/WebKit/commit/41a2db639391c73e7eba6df8c136705c213b1276
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M Source/WebKit/Platform/spi/ios/UIKitSPI.h
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
    M Source/WebKit/UIProcess/ios/UIKitUtilities.h
    M Source/WebKit/UIProcess/ios/UIKitUtilities.mm
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  -----------
  [iOS] Stop using -[UIScrollView _isInterruptingDeceleration] in WebKit
https://bugs.webkit.org/show_bug.cgi?id=259252
rdar://112334670

Reviewed by Megan Gardner.

Replace uses of `-[UIScrollView _isInterruptingDeceleration]` with a combination of `-isTracking`
and `-isDecelerating` instead. We currently use this SPI for two purposes: determining view
stability and preventing some gestures from firing when tapping to interrupt momentum scrolling.

Note that the only case I found where `decelerating && tracking` yields different results than
`_isInterruptingDeceleration` is the case where, after interrupting scroll view decleration with a
tap, `tracking` will be `NO` while `_isInterruptingDeceleration` is still `YES`. However, this
shouldn't matter to WebKit because `-gestureRecognizerShouldBegin:` has already been invoked on the
gesture recognizers that care about scroll view deceleration (i.e. touch events, synthetic click),
and `decelerating` is still set to `YES` so the view stability heuristic would still report unstable
state.

* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView scrollViewWillBeginDecelerating:]):
(-[WKWebView _viewStabilityState:]):

When determining view stability, we currently return YES if `-_isInterruptingDeceleration` is set.
This is actually redundant since:

1.  The resulting view stability `OptionSet` is only checked to see whether or not it's empty, so
    the actual values of the flags returned don't influence any behavior (i.e. it's just for
    debugging and readability).

2.  We already consult `-isDecelerating` right below, which is set to `YES` over the course of
    `-_isInterruptingDeceleration`, so in all cases where we would've considered the view to be in
    unstable state due to `-_isInterruptingDeceleration`, we would also consider it to be in
    unstable state regardless, due to the fact that the scroll view is decelerating.

* Source/WebKit/UIProcess/ios/UIKitUtilities.h:
* Source/WebKit/UIProcess/ios/UIKitUtilities.mm:
(-[UIScrollView _wk_isInterruptingDeceleration]):

Add a new category method that implements a helper method `-_wk_isInterruptingDeceleration`; this
acts as a drop-in replacement for `-_isInterruptingDeceleration`, that's suitable for current uses
within WebKit.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _isInterruptingDecelerationForScrollViewOrAncestor:]):
(-[WKContentView gestureRecognizer:isInterruptingMomentumScrollingWithEvent:]):

Take care of the second use of this SPI property, which prevents certain gestures (touch events and
synthetic click) from firing if the user is interrupting a momentum scroll; see comment above for
an explanation about why this should not change behavior.

Canonical link: https://commits.webkit.org/266111@main