[webkit-changes] [WebKit/WebKit] 4a615c: REGRESSION (284795 at main): [iOS] Find on Page butto...

Aditya Keerthi noreply at github.com
Sat Jan 11 15:26:34 PST 2025


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4a615c7a8d08c08f33cfecb389b06619ecb36fd8
      https://github.com/WebKit/WebKit/commit/4a615c7a8d08c08f33cfecb389b06619ecb36fd8
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2025-01-11 (Sat, 11 Jan 2025)

  Changed paths:
    M Source/WebCore/editing/FrameSelection.cpp
    M Source/WebCore/loader/FrameLoader.cpp
    M Source/WebCore/loader/HistoryController.cpp
    M Source/WebCore/page/EventHandler.cpp
    M Source/WebCore/page/LocalFrameView.cpp
    M Source/WebCore/page/LocalFrameView.h
    M Source/WebKitLegacy/mac/WebView/WebFrame.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm

  Log Message:
  -----------
  REGRESSION (284795 at main): [iOS] Find on Page buttons do not move to next result on pdfbooksworld.com
https://bugs.webkit.org/show_bug.cgi?id=285777
rdar://142585912

Reviewed by Abrar Rahman Protyasha and Wenson Hsieh.

284795 at main marked scrolling due to selection revealing as a "user scroll", to
avoid jumpiness on back navigation, when the user has made a selection.

However, simply marking selection revealing as a user scroll breaks scrolling
to reveal found matches in <iframe>s with scrolling="no". This is due to an
early return in `LocalFrameView::scrollRectToVisibleInChildView`, since the
user cannot actually scroll the frame through interaction, when scrolling="no".

To preserve the fix in 284795 at main, without breaking find on page, split user
scrolls into explicit (driven by interaction) and implicit (as the result of
performing another action). Then, `scrollRectToVisibleInChildView` is only
made to bail early if the last user scroll was explicit. This ensures that
<iframe>s with scrolling="no" can continue to be scrolled for the purposes of
revealing found matches.

* Source/WebCore/editing/FrameSelection.cpp:
(WebCore::FrameSelection::revealSelection):

Scrolling due to selection revealing continue to be marked as user scrolls
for the purpose of preserving the fix in 284795 at main. However, they are
marked "implicit", since the user is not scrolling via interaction.

* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::open):
(WebCore::FrameLoader::loadSameDocumentItem):
* Source/WebCore/loader/HistoryController.cpp:
(WebCore::HistoryController::recursiveUpdateForCommit):
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::setFrameWasScrolledByUser):
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::reset):
(WebCore::LocalFrameView::scrollRectToVisibleInChildView):

Only ignore scrolls due to user interaction when scrolling="no".

(WebCore::LocalFrameView::enableSpeculativeTilingIfNeeded):
(WebCore::LocalFrameView::show):
(WebCore::LocalFrameView::wasScrolledByUser const):
(WebCore::LocalFrameView::setLastUserScrollType):
(WebCore::LocalFrameView::setWasScrolledByUser): Deleted.
* Source/WebCore/page/LocalFrameView.h:
* Source/WebKitLegacy/mac/WebView/WebFrame.mm:
(-[WebFrame _userScrolled]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
(TEST(WebKit, ScrollToFoundRangeInNonScrollableIframe)):

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



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications


More information about the webkit-changes mailing list