Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 07987eceb51e2fbcdf9a8bb74ce6e7e2c2a7b9a8
https://github.com/WebKit/WebKit/commit/07987eceb51e2fbcdf9a8bb74ce6e7e2c2a7b9a8
Author: Cole Carley <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm
Log Message:
-----------
Cherry-pick 309923@main (ba1daf397dd0).
https://bugs.webkit.org/show_bug.cgi?id=310575
docs.github.com: Find in page scrolls to wrong location
rdar://170477571
https://bugs.webkit.org/show_bug.cgi?id=310575
Reviewed by Ryosuke Niwa.
The problem is that WebFoundTextRangeController::scrollTextRangeToVisible
relies on VisualSelection to scroll. Some matches may not produce a valid
selection (typically due to elements styled with user-select: none), so
during the canonicalization process, the range is collapsed,
and scrolling is broken.
The FindController uses FrameSelection::revealSelection, which calls
LocalFrameView::scrollRectToVisible. This approach does not rely on whether
we have a valid selection or not. The solution was to copy this approach
and call LocalFrameView::scrollRectToVisible directly in
WebFoundTextRangeController::scrollTextRangeToVisible.
* Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp:
(WebKit::WebFoundTextRangeController::scrollTextRangeToVisible):
(WebKit::WebFoundTextRangeController::simpleRangeFromFoundTextRange):
I have added an API test, WebKit.ScrollToUserSelectNoneFoundRange to
exercise the new code path. Without my changes, the test times out
waiting for scroll.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
(TEST(WebKit, ScrollToUserSelectNoneFoundRange)):
Canonical link: https://commits.webkit.org/309923@main
Canonical link: https://commits.webkit.org/305877.303@webkitglib/2.52
Commit: 30ea0e4c7036069d2be66b2c880fbc366736341f
https://github.com/WebKit/WebKit/commit/30ea0e4c7036069d2be66b2c880fbc366736341f
Author: Chris Dumez <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/Platform/IPC/Decoder.cpp
Log Message:
-----------
Cherry-pick 309907@main (59d1396282e4).
https://bugs.webkit.org/show_bug.cgi?id=310691
Potential null dereference of wrappedDecoder in Decoder::unwrapForTesting()
https://bugs.webkit.org/show_bug.cgi?id=310691
Reviewed by Kimmo Kinnunen.
Potential null dereference of wrappedDecoder in Decoder::unwrapForTesting()
since Decoder::create() can return nullptr. Early return instead if this
happens.
* Source/WebKit/Platform/IPC/Decoder.cpp:
(IPC::Decoder::unwrapForTesting):
Canonical link: https://commits.webkit.org/309907@main
Canonical link: https://commits.webkit.org/305877.304@webkitglib/2.52
Commit: 7b9685c5a6beb309bc6f1cb939bc849748ee924d
https://github.com/WebKit/WebKit/commit/7b9685c5a6beb309bc6f1cb939bc849748ee924d
Author: Sebastian Krzyszkowiak <[email protected]>
Date: 2026-03-25 (Wed, 25 Mar 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp
Log Message:
-----------
Cherry-pick 309900@main (1f39a7f2d79b).
https://bugs.webkit.org/show_bug.cgi?id=289333
[GTK] LayerTreeHost: Update rendering after manipulating transient zoom
https://bugs.webkit.org/show_bug.cgi?id=289333
Reviewed by Carlos Garcia Campos.
Otherwise nothing requests frame to be redrawn and nothing is changed
on screen unless something else happens to draw as well.
* Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:
(WebKit::LayerTreeHost::adjustTransientZoom):
Canonical link: https://commits.webkit.org/309900@main
Canonical link: https://commits.webkit.org/305877.305@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/9e70506e3cd6...7b9685c5a6be
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
