Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 9543685f56f59082e6ba15377fc41158d63b3694
https://github.com/WebKit/WebKit/commit/9543685f56f59082e6ba15377fc41158d63b3694
Author: Zak Ridouh <[email protected]>
Date: 2026-09-01 (Tue, 01 Sep 2026)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h
M Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] Zoom-to-reveal mispositions the focused element when the
selection is in a cross-origin iframe
https://bugs.webkit.org/show_bug.cgi?id=320041
rdar://182974019
Reviewed by Alex Christensen.
-[WKContentView rectToRevealWhenZoomingToFocusedElement] builds the rect that
-[WKContentView _zoomToRevealFocusedElement] reveals out of two pieces of
focused element state, and under site isolation only one of them is in
main-frame coordinates.
The selection half is already correct: 318296@main moved the conversion of the
editor state's selection geometry into the web process, so both
selectionBoundingRectInRootViewCoordinates() and interactionRect (converted in
convertFocusedElementInformationRectsToMainFrameCoordinates()) are in main-frame
coordinates, and intersecting them anchors the reveal at the right place. No
test covered the reveal rect itself, so add one.
lastInteractionLocation is not converted. It is the tap location as delivered to
the frame's own process, so for a cross-origin iframe it is in that subframe's
root-view coordinates while interactionRect is in main-frame coordinates.
Comparing the two mixes coordinate spaces: for an element that cannot contain a
text selection (a <select>, a date input) inside an offset iframe the
containment check fails and the reveal loses the tapped point entirely, and it
can also succeed spuriously and reveal a 1x1 rect at the wrong location.
Convert lastInteractionLocation together with the other focused element rects,
in the same round trip, so both sides of the comparison are in the same space.
A focused element in the main frame converts nothing, as before.
The new API test covers the selection path. Exercising the tapped-point path
would need a synthetic tap, which TestWebKitAPI has no infrastructure for.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
* Source/WebKit/UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm:
(-[WKWebView _rectToRevealWhenZoomingToFocusedElementForTesting]):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::convertFocusedElementInformationRectsToMainFrameCoordinates):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::(SiteIsolation,
ZoomToRevealFocusedElementRectIsInMainFrameCoordinates)):
Canonical link: https://commits.webkit.org/320242@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
