Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: cfed61549b572670717859637909a48031feb133
https://github.com/WebKit/WebKit/commit/cfed61549b572670717859637909a48031feb133
Author: Jessica Cheung <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M Source/WebCore/Headers.cmake
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/page/DragController.cpp
M Source/WebCore/page/DragController.h
M Source/WebCore/page/EventHandler.cpp
M Source/WebCore/page/EventHandler.h
A Source/WebCore/platform/DragEventTargetData.h
M Source/WebKit/CMakeLists.txt
M Source/WebKit/DerivedSources-input.xcfilelist
M Source/WebKit/DerivedSources.make
M Source/WebKit/Scripts/webkit/messages.py
A Source/WebKit/Shared/DragEventForwardingData.h
A Source/WebKit/Shared/DragEventForwardingData.serialization.in
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Source/WebKitLegacy/mac/WebView/WebView.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] Drag & Drop within remote frame is nonfunctional
https://bugs.webkit.org/show_bug.cgi?id=301963
rdar://160806781
Reviewed by Aditya Keerthi and Alex Christensen.
Original patch by pascoej. Thanks to achristensen07 for suggesting this
new approach.
In certain site isolation cases, dragging and dropping on macOS/iOS causes
a navigation when dropping items instead of a drop event.
The default mode for drag and drop is to load, which would then
trigger a navigation. When dropping with the presence of remote frames,
there is no logic to support this functionality and the behavior defaults
to load. To fix this unexpected behavior, implement support
for drag and drop with remote frames. This includes finding the correct
destination frame, and propagating the drag and drop action to the target
frame.
* Source/WebCore/Headers.cmake:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
Add new files that supports DragEventTargetData and DragEventForwardingData.
The DragEventForwardingData struct contains the information for propagating the
event
to the target frame.
* Source/WebCore/page/DragController.cpp:
(WebCore::DragController::performDragOperation):
* Source/WebCore/page/DragController.h:
Alter the original code to factor in the presence of remote frames.
If a remote frame (not the current frame) is the destination of the
drop event, return a DragEventTargetData that represents the remote frame ID.
This
remote frame ID will be used as the new destination frame ID. Otherwise,
handle cases for edit and load accordingly using the current frame instead
of the main frame.
* Source/WebCore/page/EventHandler.cpp:
(WebCore::contentFrameForNode):
(WebCore::EventHandler::updateDragAndDrop):
(WebCore::EventHandler::cancelDragAndDrop):
(WebCore::EventHandler::performDragAndDrop):
* Source/WebCore/page/EventHandler.h:
The return value in EventHandler::performDragAndDrop indicates if a drop event
was successfully handled or not.
Check if the subframeForTargetNode is a remote frame or a local frame.
If the subframe is a remote frame, return the targetFrameID.
If the current frame is the owner of the target frame for the drop event,
there are two cases: local and remote frame. If the target frame is a local
frame,
simply call performDragAndDrop on the target frame. In this case, the target
frame
is accessible. If the target frame is remote, the target frame is not accessible
in this context. Thus, populate DragEventTargetData targetFrameID to be used to
propagate to the remote frame.
Otherwise, if it's at the target, create DataTransfer::createForDrop and
return whether the drop event was successfully executed.
* Source/WebCore/platform/DragEventTargetData.h: Added.
* Source/WebKit/CMakeLists.txt:
* Source/WebKit/DerivedSources-input.xcfilelist:
* Source/WebKit/DerivedSources.make:
* Source/WebKit/Scripts/webkit/messages.py:
(types_that_cannot_be_forward_declared):
(headers_for_type):
* Source/WebKit/Shared/DragEventForwardingData.h: Added.
* Source/WebKit/Shared/DragEventForwardingData.serialization.in: Added.
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Add new files for the DragEventTargetData and DragOperationResult variants.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::propagateDragAndDrop):
(WebKit::WebPageProxy::performDragOperation):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:
DragOperationResult contains either a boolean that indicates the equivalent of
the DragEventHandled in DragEventTargetData (whether the drag/drop event was
successful),
or a DragEventForwardingData struct that neatly packages all the relevant
information needed
for the WebPageProxy to forward the drag event to the correct frame.
DragEventForwardingData
consists of the targetFrameID and sandbox extension handles needed.
WebPageProxy::performDragOperation utilizes a new model for drag and drop to
include remote frames.
Previously, the code only accounted for the local main frame.
This is the current model:
1) WebPageProxy's performDragOperation is responsible for sending the initial
IPC call to WebPage::PerformDragOperation, in the context of the main frame.
2) A reply (completion handler) is received from WebPage::PerformDragOperation.
If DragEventTargetData is of DragEventHandled type, it'll indicate if the event
succeeded. In this
case, return a boolean in the completion handler.
If the type is a Frame Identifier, that means there is a frame that needs to
receive this
operation and hasn't yet. So, create a DragEventForwardingData that includes
all the information needed
for the operation and return it in the completion handler.
3) In propagateDragAndDrop, send an IPC message to WebPage::PerformDragOperation
with the DragEventForwardingData's targetFrameID. If it is still not handled
and there is another Frame
Identifier that is not the current frame ID passed in, a propagation must
happen again.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::performDragControllerAction):
(WebKit::WebPage::performDragOperation):
(WebKit::WebPage::willPerformLoadDragDestinationAction):
(WebKit::WebPage::mayPerformUploadDragDestinationAction):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
DragEventTargetData used in WebPage consists of a DragEventHandled that
represents if the drag event
was successful or not, and a Frame Identifier that represents the frameID of the
target. Also, change the sandboxing logic to use SandboxExtension handles
instead. This is because
when WebPage::performDragOperation is called via IPC messages, now
there is no guaranteee that the extensions will be used in the current frame
context.
As a result, there needs to be a way to retain the SandboxExtension handles,
which
will later be utilized to create the extensions to be consumed for dropping, on
the
actual target frame.
* Source/WebKitLegacy/mac/WebView/WebView.mm:
(-[WebView _tryToPerformDataInteraction:client:global:operation:]):
(-[WebView performDragOperation:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SiteIsolation.mm:
(TestWebKitAPI::TEST(SiteIsolation, DragAndDropWithoutNavigation)):
Create an API test to ensure a navigation does not occur when dragging and
dropping.
Canonical link: https://commits.webkit.org/306143@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
