Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d67629db80a219120c04862d20b6425bc267de60
https://github.com/WebKit/WebKit/commit/d67629db80a219120c04862d20b6425bc267de60
Author: Ryosuke Niwa <[email protected]>
Date: 2026-08-06 (Thu, 06 Aug 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebFrame.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] [iOS] Caret inside a cross-site iframe renders at a wrong
location
https://bugs.webkit.org/show_bug.cgi?id=321068
Reviewed by Simon Fraser.
When text is selected (or a caret is placed) inside a cross-origin,
site-isolated
iframe, the selection and caret were drawn in the wrong place once the main
frame
had been scrolled -- shifted by the main frame's scroll offset.
The selection rects are computed in the subframe's process and mapped to
main-frame
coordinates by FrameView::convertToRootViewAcrossIsolatedFrames(), whose final
step
calls contentsToView() on the main frame's view. On iOS the local main frame's
LocalFrameView is DelegatedToNativeScrollView (set from the drawing area in
WebLocalFrameLoaderClient), so contentsToView() is the identity and the rects
stay
in main-frame content coordinates -- which is what UIKit expects, since the
WKContentView is document-sized. The main frame's RemoteFrameView proxy in the
subframe's process, however, defaulted to NotDelegated and its scrollPosition()
reflects the synced FrameScrollPosition, so contentsToView() subtracted the main
frame's scroll offset. The result was a cross-origin selection rect offset by
exactly the main-frame scroll, while a same-origin selection (which skips this
conversion) was correct.
Fix this by mirroring the drawing area's delegated-scrolling mode onto the main
frame's RemoteFrameView, so the proxy performs the same coordinate conversions
as
the real main frame in the process that hosts it. This is correct
cross-platform:
on iOS the mode is DelegatedToNativeScrollView (identity), and on macOS it is
DelegatedToWebKit, which still subtracts scroll -- matching the local main frame
there. The synced childFrameOwnerToRootContentTransform is already
scroll-invariant;
only the final contentsToView() was wrong.
Test:
TestWebKitAPI.SiteIsolation.SelectionInCrossOriginIframeTracksMainFrameScroll
* Source/WebKit/WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::loadDidCommitInAnotherProcess): Call
updateRemoteMainFrameViewDelegatedScrolling when the main frame transitions from
local to remote.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::WebPage): Call updateRemoteMainFrameViewDelegatedScrolling
when
the page is created with a remote main frame.
(WebKit::WebPage::updateRemoteMainFrameViewDelegatedScrolling): Added.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::(SiteIsolation,
SelectionInCrossOriginIframeTracksMainFrameScroll)):
Added SelectionInCrossOriginIframeTracksMainFrameScroll, comparing a same-origin
iframe (reference) against a cross-origin one under main-frame scroll.
Canonical link: https://commits.webkit.org/318716@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
