[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