Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 5063252ff004392b50d68bfc2aa7d7d44564a5b0
https://github.com/WebKit/WebKit/commit/5063252ff004392b50d68bfc2aa7d7d44564a5b0
Author: Wenson Hsieh <[email protected]>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKitCocoa/cursor-styles.html
M Tools/TestWebKitAPI/Tests/WebKitCocoa/iOSMouseSupport.mm
M Tools/TestWebKitAPI/cocoa/TestWKWebView.h
M Tools/TestWebKitAPI/cocoa/TestWKWebView.mm
Log Message:
-----------
Move off of UIKit SPI:
`-_pointerInteraction:regionForRequest:defaultRegion:completion:`
https://bugs.webkit.org/show_bug.cgi?id=260662
rdar://114331132
Reviewed by Tim Horton.
Refactor some iOS-specific logic for computing pointer regions when using
`UIPointerInteraction`,
such that we no longer require this UIKit SPI delegate method for
asynchronously retrieving regions:
`-_pointerInteraction:regionForRequest:defaultRegion:completion:`. Rather than
performing the hit-
test and then invoking the completion handler when the results arrive from the
web process, we
instead cache the last computed `UIPointerRegion` on the content view and
continuously perform
position information updates to update this cached `UIPointerRegion`, until we
reach a state where
the most recent `UIPointerRegionRequest` is satisfied by the cached
`_positionInformation`. This
actually allows us to simplify a bit of the logic here for updating pointer
regions, since we'll now
simply return `_lastPointerRegion` from the delegate method, and continuously
schedule position
information updates via `-doAfterPositionInformationUpdate:` until we catch up
to the current
pointer location.
Test: iOSMouseSupport.BasicPointerInteractionRegions
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
Remove SPI declarations that are now unused.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView cleanUpInteraction]):
(-[WKContentView pointerInteraction:regionForRequest:defaultRegion:]):
(-[WKContentView _updateLastPointerRegionIfNeeded:]):
Drive-by fix: use `[_lastPointerRegion rect]` instead of `self.bounds` when
returning a region in
the case where the entire web view is `_editable`, but the position information
is not yet up to
date. This shouldn't actually make any difference since the use of
`"WKEditablePointerRegion"` means
that we'll always use `UIAxisNeither` to avoid nudging the cursor in any
direction for this region,
but it makes visually debugging these pointer regions in Mail compose a bit
easier, since we no
longer flicker rapidly between a pointer region the size of the web view that
constraints neither
axis, and a pointer region the size of the expanded line rect that constrains
to block direction,
when UIKit asks for `-pointerInteraction:styleForRegion:`.
(-[WKContentView pointerRegionForPositionInformation:point:]):
(-[WKContentView pointerInteraction:styleForRegion:]):
Another drive-by fix: it's actually possible in shipping iPadOS to end up in a
situation where we
return an IBeam cursor that tries to align to the Y-axis, but the region is the
entire bounds of the
view (which causes the cursor to disappear altogether until the user hovers
over a different pointer
region). This is observable by hovering over the left edge of a `blockquote` on
daringfireball.net.
After the changes in this patch (but without the tweak in this method), we no
longer cause the
cursor to disappear, but we do get a visual flicker as the cursor attempts to
animate to the center
of the view bounds. It's unclear whether this is better or worse, so it's
probably better to just
fix this existing bug as a part of this refactoring:
The root cause is the fact that `-pointerRegionForPositionInformation:point:`
can return a region
the size of `self.bounds` despite the position information containing an IBeam
cursor type, if
`expandedLineRect.contains(location)` returns `false`, which is possible if the
request location is
_just_ left or right of the `expandedLineRect`. To mitigate this, I'm making it
so that we don't
attempt to constrain to the region, if the region is taller (or wider, in
vertical writing mode)
than an arbitrary length.
(-[WKContentView
_pointerInteraction:regionForRequest:defaultRegion:completion:]): Deleted.
* Source/WebKit/UIProcess/ios/WKScrollView.mm:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/cursor-styles.html: Added.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/iOSMouseSupport.mm:
(-[TestPointerRegionRequest initWithLocation:]):
(-[TestPointerRegionRequest location]):
(-[TestWKWebView pointerInteraction]):
(-[TestWKWebView pointerInfoAtLocation:]):
Additionally, write some test infrastructure and a basic API test to exercise
this functionality by
calling directly into the `UIPointerInteractionDelegate` methods to grab the
cursor styles and
regions for several common scenarios (e.g. CSS `cursor` property, editable
regions, non-editable
text, links).
* Tools/TestWebKitAPI/cocoa/TestWKWebView.h:
* Tools/TestWebKitAPI/cocoa/TestWKWebView.mm:
(-[WKWebView elementRectFromSelector:]):
(-[WKWebView elementMidpointFromSelector:]):
Canonical link: https://commits.webkit.org/267361@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
