[webkit-changes] [WebKit/WebKit] 506325: Move off of UIKit SPI: `-_pointerInteraction:regio...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5063252ff004392b50d68bfc2aa7d7d44564a5b0
      https://github.com/WebKit/WebKit/commit/5063252ff004392b50d68bfc2aa7d7d44564a5b0
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  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