Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 41a2db639391c73e7eba6df8c136705c213b1276
https://github.com/WebKit/WebKit/commit/41a2db639391c73e7eba6df8c136705c213b1276
Author: Wenson Hsieh <wenson_hs...@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
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
