[webkit-changes] [WebKit/WebKit] 2e3f11: [visionOS] Find in HTML note obscures matches when...

[Aditya Keerthi]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2e3f11b2736f256ef25d919e5a7ebb7294ac9be9
      https://github.com/WebKit/WebKit/commit/2e3f11b2736f256ef25d919e5a7ebb7294ac9be9
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2023-08-31 (Thu, 31 Aug 2023)

  Changed paths:
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm

  Log Message:
  -----------
  [visionOS] Find in HTML note obscures matches when they are at the top
https://bugs.webkit.org/show_bug.cgi?id=260982
rdar://109165939

Reviewed by Wenson Hsieh.

On visionOS, the find bar initially appears in the scroll view's inset area.
As the scroll view is scrolled, the find bar's frame is adjusted to ensure
it is always at the top of the currently visible rect. Both these behaviors are
implemented by UIKit.

When matches are found, scrolling is performed to make them visible. This is
achieved by using `-[WKWebView _scrollToRect:origin:minimumScrollDistance:]`.
However, that method always enforces a minimum content offset of (0, 0). This
is incompatible with the find bar's position, since for matches at the top of
the scroll view, a scroll to (0, 0) is forced, even when match is already visible.
The forced scroll to (0, 0) then ends up obscuring the match, as the find bar's
position is adjusted to keep it at the top.

Fix by accounting for content insets when determining the minimum content offset
for targeted scrolling.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _initialContentOffsetForScrollView]):
(constrainContentOffset):
(-[WKWebView _scrollToRect:origin:minimumScrollDistance:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
(TEST):

Use a 500ms delay to ensure that scrolling did not occur. Waiting for two
presentation updates is unfortunately insufficient.

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