macOS: forward Finder drops through WKWebView

[dominicletz]

Summary

WKContentView receives Finder drag events before the WKWebView subclass. The subclass hooks therefore do not run, and the page does not receive DataTransfer.files.

This change:

• installs a runtime bridge on WebKit's private drag destination view;
• registers file URLs and file promises on that view;
• keeps WebKit's original drag handlers so normal web drop events remain active;
• reapplies the bridge after view attachment and webview rebuild;
• extends the file-input fixture with a manual file-manager drop target.

Tests

• MIX_ENV=test NO_WX=1 mix test --exclude e2e
• MIX_ENV=test NO_WX=1 mix test.e2e
• ./scripts/build_macos.sh

---

Note

Medium Risk
Relies on runtime method swizzling and private WebKit view class names, which can break on OS/WebKit updates and is harder to validate automatically than public APIs.

Overview
Finder drag-and-drop into the webview was ineffective because WebKit’s internal WKContentView/WKView handles drags before FileDropWebView overrides run, so pages never got DataTransfer.files.

FileDropWebView now discovers those private subviews, registers file URL and file-promise pasteboard types on them, and installs a one-time FileDropBridge via Objective-C runtime swizzling. The bridge delegates to WebKit’s saved implementations while OR-ing in file-drop acceptance (including .copy when WebKit would return no operation). Installation runs on init and again in viewDidMoveToWindow (plus an async pass) so webview.rebuild still picks up the bridge.

Docs note the private drag bridge; the file_input.html fixture gains a #drop-target drop zone, and the shared E2E asserts that element is present (actual Finder drops remain manual).

^{Reviewed by Cursor Bugbot for commit b6a20b4. Configure here.}