fix(v2): prevent DragAndDrop from triggering OnDomReady on Linux#5214
fix(v2): prevent DragAndDrop from triggering OnDomReady on Linux#5214leaanthony wants to merge 1 commit into
Conversation
Two bugs were fixed: 1. onDragDrop() returned FALSE, signaling GTK that the drop was not handled. This allowed WebKit to process the drop as a navigation, reloading the page and triggering DomReady. Fix: return TRUE to indicate the drop was consumed. 2. When both DisableWebViewDrop and EnableFileDrop were true, gtk_drag_dest_unset() was called before the custom drag handlers were connected. This removed the webview as a drag destination, so the custom handlers never fired. Fix: when EnableFileDrop is true, unset WebKit's default DnD then re-register the webview as a drag destination with only the text/uri-list target for custom handling. Fixes #3563
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🤖 PR Triage Review ✅ Accepted Prevents DragAndDrop from triggering OnDomReady on Linux (v2). Fixes event timing issue. Platform: Linux (v2) Next Steps: Dispatching for Linux testing. Reviewed by Wails PR Reviewer Bot |
Summary
Fixes #3563
Two bugs were fixed in the Linux frontend's drag-and-drop handling:
OnDomReady triggered on every DnD:
onDragDrop()returnedFALSE, signaling GTK that the drop was not handled. This allowed WebKit to process the drop as a navigation (loading the dropped file), which reloaded the page and triggeredDomReady. Fix: returnTRUEto indicate the drop was consumed.DisableWebViewDrop breaks custom DnD: When both
DisableWebViewDropandEnableFileDropwere true,gtk_drag_dest_unset()was called before the custom drag handlers were connected. This removed the webview as a drag destination entirely, so the custom handlers never fired. Fix: whenEnableFileDropis true, unset WebKit's default DnD, then re-register the webview as a drag destination with only thetext/uri-listtarget for custom handling.Changes
v2/internal/frontend/desktop/linux/window.c:onDragDrop(): returnTRUEinstead ofFALSESetupWebview(): restructured DnD setup to always callgtk_drag_dest_set()whenenableDragAndDropis truev2/test/3563/Test plan
EnableFileDrop: trueOnDomReadyis NOT triggered again after the dropEnableFileDrop: true+DisableWebViewDrop: true