[webkit-changes] [WebKit/WebKit] 703dab: REGRESSION (262853 at main): Pan gestures that scroll...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 703dabd84f9ce9f920329acd116d21c80fe7010c
      https://github.com/WebKit/WebKit/commit/703dabd84f9ce9f920329acd116d21c80fe7010c
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-05-02 (Tue, 02 May 2023)

  Changed paths:
    A LayoutTests/fast/events/ios/scrolling-with-pan-gesture-should-not-trigger-click-expected.txt
    A LayoutTests/fast/events/ios/scrolling-with-pan-gesture-should-not-trigger-click.html
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  -----------
  REGRESSION (262853 at main): Pan gestures that scroll should not dispatch synthetic clicks
https://bugs.webkit.org/show_bug.cgi?id=256182
rdar://108553019

Reviewed by Tim Horton.

262853 at main allowed the synthetic tap gesture to recognize simultaneously with pan gestures, which
had the unintended consequence of causing synthetic clicks to be dispatched when scrolling the page
for very short distances (that is, shorter than the tap gesture's default allowable movement
distance of 45pt).

To prevent this from happening while keeping the original fix in 262853 at main intact, we continue to
allow simultaneous recognition, but add explicit logic to suppress the synthetic click action from
being sent if we're actually scrolling any enclosing scroll view (including subscrollable regions in
web views).

See below for more details.

Test: fast/events/ios/scrolling-with-pan-gesture-should-not-trigger-click.html

* LayoutTests/fast/events/ios/scrolling-with-pan-gesture-should-not-trigger-click-expected.txt: Added.
* LayoutTests/fast/events/ios/scrolling-with-pan-gesture-should-not-trigger-click.html: Added.

Add a new layout test to exercise the change by verifying that scrolling for a short distance by
panning the web view does not additionally dispatch click events to the page.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _hasEnclosingScrollView:matchingCriteria:]):

Factor out the enclosing scroll view traversal logic below into a helper method, which takes a
function and calls that function with each enclosing `UIScrollView` in the ancestor chain, starting
with the given `scrollView` (or the web view's main scroll view if none is specified), in search of
the first web view where the given function returns `YES`.

Note that we remove the restriction here that currently makes us bail upon hitting the web view's
scroller; this allows the fix to work as intended for Mail (and any other apps that embed web views
inside their own scrollers).

(-[WKContentView _isPanningScrollViewOrAncestor:]):

Use the above helper method to check whether we're actively panning any ancestor scroll view, by
returning `YES` if and only if:

•   The scroll view's `decelerating` flag is set.
•   The scroll view's `dragging` flag is set.
•   The scroll view's pan gesture recognizer is recognizing or about to begin recognizing (i.e.
    state is `Began`, `Changed` or `Ended`).

In my testing, the combination of the three checks above is required to avoid all scenarios where
it's currently possible to swipe/pan really quickly and end up with both scrolling, and a synthetic
click.

(-[WKContentView _isInterruptingDecelerationForScrollViewOrAncestor:]):

Rewrite this in terms of the `-_hasEnclosingScrollView:matchingCriteria:` helper method above.

(-[WKContentView gestureRecognizerShouldBegin:]):

Don't allow taps to begin if we're either (1) panning an enclosing scroll view, or (2) interrupting
momentum scrolling in an enclosing scroll view.

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