fix(desktop): make drag & drop work on Windows - #272
Merged
Merged
Conversation
Windows has no native file-drop handler. The only path to the `wails:file-drop` event is the webview's JS drop listener posting the dropped files back to Go via postMessageWithAdditionalObjects, which Wails installs exclusively inside the JS runtime's OnFileDrop(). The frontend never called it, so the Go-side handler in main.go could never fire. macOS and Linux handle the drop natively in the window, which is why it worked there. Two independent blockers, both fixed: - Register the JS runtime's OnFileDrop on mount in Wails mode, with useDropTarget disabled since the default re-checks elementFromPoint against --wails-drop-target and the drag overlay is conditionally rendered. Unregister on destroy. - Stop setting DisableWebViewDrop on Windows, where it calls AllowExternalDrag(false) and prevents the webview from receiving the external drag at all. macOS and Linux keep it so the webview does not handle the file itself. Refs #114
javi11
force-pushed
the
fix/windows-file-drop
branch
from
September 6, 2026 14:10
d6d5d74 to
33cb660
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes Windows drag & drop (#114) without moving to the Wails v3 alpha/beta. The failure was postie's own wiring, not the upstream WebView2 bug the issue assumed.
Root cause
The two platforms reach the same
wails:file-dropevent by completely different routes:darwin/WailsWebView.mperformDragOperation:, GTK on Linux) and emitswails:file-dropdirectly. No JS involved, which is whyruntime.OnFileDropinmain.goworked there.droplistener callschrome.webview.postMessageWithAdditionalObjects("file:drop:x:y", files), andwindows/frontend.goturns that message intowails:file-drop.That JS listener is installed only inside the JS runtime's
OnFileDrop(), which the frontend never called —+page.svelteregistered its owndrophandler that stops navigation but posts nothing back. So on Windows nothing ever reached Go.Second, independent blocker:
DisableWebViewDrop: truecallschromium.AllowExternalDrag(false)on Windows, so the webview refuses the external drag outright and no JSdropevent fires at all.Changes
frontend/src/routes/+page.svelte—registerWailsFileDrop()on mount dynamically imports the Wails runtime and callsOnFileDrop(() => {}, false). The callback is intentionally empty; the work still happens in the Go handler.useDropTarget: falsebecause the default re-checksdocument.elementFromPointagainst--wails-drop-target, which the conditionally rendered drag overlay breaks.OnFileDropOffruns on destroy, guarded by adestroyedflag so a late-resolving import can't register after teardown. Web mode short-circuits before the import.main.go—DisableWebViewDropis nowruntime.GOOS != "windows".Notes
Wails v2.14.0 is out but contains only a WebView2 bootstrapper fix, nothing drag-related. v3 would mean a full API migration (
EnableFileDrop,data-file-drop-target,WindowFilesDropped) for a problem we don't have.Test plan
gofmt -l main.goclean,go vet ./...clean, hostgo build ./...passesbun run buildsucceeds; the dynamic import resolvesbun run check— 2 errors, both pre-existing and in untouched files (ServerSectionServerData.name,DashboardHeadercountinMessageObject)GOOS=windowsfails on unrelated cgo deps (rapidyenc,par2go/internal/parpar).If the drop lands but the overlay stays stuck visible, that's wails#5780, separate from this fix.