Bug 323277 – REGRESSION(303828@main): [GTK][WPE] dataTransfer.files is empty when files are dropped from the file manager

• Status: NEW
• Component: WebKitGTK

[Hayden Barnes]

Since 303828@main, DataTransfer::allowsFileAccess() in
Source/WebCore/dom/DataTransfer.h returns false on every port except
Cocoa. A file dragged from the file manager into a page arrives with
an empty dataTransfer.files, so drop-to-upload does not work on
WebKitGTK or WPE. Bug 320301 reports the same failure against
WebKitGTK 2.52.5 in Epiphany and MiniBrowser.

Steps to reproduce:
1. Open the attached drop.html. It reports dataTransfer.files.length
   in the window title.
2. Drag a file from Files (Nautilus) onto the red box.
3. The title reads files=0. Before 303828@main it read files=1.

Cause: the disable was the workaround for CVE-2025-13947, and comment
0 on bug 303434 says the narrow fix was tried first and failed. The
defect it worked around is in SelectionData. setURIList() promoted
every file:// line into m_filenames, and a page can write
text/uri-list itself through DataTransfer.setData() during a drag it
started, so a page could name file:///etc/passwd, receive its own
drag back, and read it. The uri-list is web-writable text. The
filename list is a filesystem grant. Bug 52094, open since 2011, is
the same conflation from another angle.

Fix: separate the two channels rather than flip the policy back.
setURIList() stops writing m_filenames. Filenames are set by the
UIProcess drop targets from a real GdkDrop or GdkDragContext, travel
in their own SelectionData IPC field, and are cleared by
WebPageProxy::startDrag() on the way up. On GTK4 the portal file list
takes precedence over a parallel uri-list, web drag exports drop
file:// lines, import rejects file URIs naming a foreign host, and
DragData denies filenames when DragApplicationFlags::IsSource is set.
Only then does allowsFileAccess() return forFileDrag() for GTK and
WPE. Paste stays denied, so the expectation 303828@main added for
paste-image-does-not-reveal-file-url is unchanged.

Tests: drag and drop cannot be driven from WebKitTestRunner on GTK
(bug 157179), so the patch adds a GLib API test, TestDragAndDrop,
that feeds the production DropTarget path the inputs a real drop
supplies and asserts dataTransfer.files from JavaScript after the IPC
round trip, plus SelectionData and DropTargetState unit tests in
TestWebCore: 11 API tests and 33 unit tests. The commit message
covers the negative controls and what stays out of scope.

Bug 271957 is not visible to me. I would appreciate a maintainer
checking the change against that reproducer.

HeroDevs is sponsoring this work.

Pull request to follow.

[Hayden Barnes]

Created attachment 481279 [details]
Drop target that reports dataTransfer.files.length in the title

[Hayden Barnes]

Pull request: https://github.com/WebKit/WebKit/pull/73114