Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 703dabd84f9ce9f920329acd116d21c80fe7010c
https://github.com/WebKit/WebKit/commit/703dabd84f9ce9f920329acd116d21c80fe7010c
Author: Wenson Hsieh <[email protected]>
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@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@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@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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
