Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0c1e2e176c45278dc7e08a62d3e8f44f68a93efd
https://github.com/WebKit/WebKit/commit/0c1e2e176c45278dc7e08a62d3e8f44f68a93efd
Author: Ryosuke Niwa <[email protected]>
Date: 2026-09-22 (Tue, 22 Sep 2026)
Changed paths:
M Source/WebCore/page/ios/EventHandlerIOS.mm
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ios/DragAndDropTestsIOS.mm
Log Message:
-----------
[Site Isolation] [iOS] Drag events report incorrect screen coordinates in
subframes
https://bugs.webkit.org/show_bug.cgi?id=324907
Reviewed by Wenson Hsieh.
EventHandler::dispatchDragEvent() hands the drag event's globalPosition
straight to DragEvent as
its screenLocation, and dragstart uses m_mouseDownEvent, which
tryToBeginDragAtPoint() builds. On
iOS a mouse event's globalPosition is a point in the top-level page's root view
rather than device
screen space, but tryToBeginDragAtPoint() computed it as windowToContents() of
the client position,
which is this frame's contents coordinates. In a subframe that subtracts the
frame's own offset and
scroll, so dragstart reported screenX/screenY equal to clientX/clientY; with
site isolation a
cross-origin iframe was off by its offset within the page for the same reason.
Map the adjusted client position, which stays in the local root frame's root
view at every level of
the recursion, up to the main frame's root view with
convertToRootViewAcrossIsolatedFrames(). That
walks the ancestor chain through any parent RemoteFrameView, applying each
frame's transform and
scroll, and returns the point unchanged when the main frame is in this process.
Also stop transforming globalPosition into remote frame coordinates when
handing a drag off to
another process: unlike the client position, it is not frame-relative, so it
must survive the hop
unchanged, matching what WebPageProxy::mouseEventHandlingCompleted() already
does for mouse events.
Neither of those two values is observable today -- tryToBeginDragAtPoint()
ignores the
globalPosition argument it is passed, and
requestAdditionalItemsForDragSession() returns early in a
process without a local main frame -- but leaving them re-based is a trap for
whoever makes those
paths reachable. Now that the position is computed in WebCore, the EventHandler
parameter and the
transformedGlobalPosition it feeds are unused end to end; removing them can be
a separate change.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ios/DragAndDropTestsIOS.mm
* Source/WebCore/page/ios/EventHandlerIOS.mm:
(WebCore::EventHandler::tryToBeginDragAtPoint):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::requestDragStart):
(WebKit::WebPage::requestAdditionalItemsForDragSession):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ios/DragAndDropTestsIOS.mm:
(TestWebKitAPI::dragStartScreenCoordinatesInOffsetIframe):
(TestWebKitAPI::TEST(DragAndDropTests,
DragStartScreenCoordinatesInSameSiteOffsetIframe)):
(TestWebKitAPI::TEST(DragAndDropTests,
DragStartScreenCoordinatesInCrossOriginOffsetIframe)):
Canonical link: https://commits.webkit.org/321663@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
