[webkit-changes] [WebKit/WebKit] 9935bf: [iPad] Trackpad scrolling in nested scroll views s...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9935bf6fc5f092db434ce5350cce03cc07267021
      https://github.com/WebKit/WebKit/commit/9935bf6fc5f092db434ce5350cce03cc07267021
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-12-05 (Thu, 05 Dec 2024)

  Changed paths:
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm

  Log Message:
  -----------
  [iPad] Trackpad scrolling in nested scroll views sometimes only works during the momentum phase
https://bugs.webkit.org/show_bug.cgi?id=284081
rdar://140922601

Reviewed by Richard Robinson.

Currently, the logic in `-scrollView:handleScrollUpdate:completion:` attempts to call the completion
handler with `handled := YES` in the case where handling a scroll update wouldn't result in
scrolling anyways. To achieve this, we currently ask the given `scrollView` whether it's scrollable,
and save the result in a local variable `isHandledByDefault`.

However, in the case of nested `WKChildScrollView`s, this can lead to unpredicable results if the
inner scroll view is scrollable and the outer `WKScrollView` is non-scrollable; this is because
UIKit may deliver the async scroll event to either `UIScrollView` in this case (depending on the
hash table iteration order of an internal `NSSet<UIGestureRecognizer *> *`). If the scroll update is
delivered to the inner child scroll view, the wheel deltas successfully trigger scrolling because
the child scroll view has `-isScrollEnabled := YES`. However, if the scroll update is delivered to
the unscrollable `WKScrollView` instead, scrolling fails because `isHandledByDefault := NO`.

To fix this, we instead set `isHandledByDefault` to `YES` if and only if there are no scrollable
child scroll views underneath the scroll update location. This makes the logic robust regardless of
which subscrollable container receives the update in UIKit.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView scrollView:handleScrollUpdate:completion:]):

Drive-by fix: avoid calling the completion handler 2 times in the case where the web view has been
destroyed and the event is non-cancelable.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:

Expose an internal helper method, for use in `WKWebViewIOS` above.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _hasEnclosingScrollView:matchingCriteria:]):
* Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm:
(TEST(WKScrollViewTests, OverscrollBehaviorAndOverflowHiddenOnRootShouldNotPreventScrolling)):
(TEST(WKScrollViewTests, OverscrollBehaviorShouldNotPreventScrolling)): Deleted.

Augment an existing API test to exercise this change.

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



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications