Dropping files (ondrop) doesn't work on Windows

[Boscop]

Problem

Dropping files (ondrop) doesn't work on Windows, the even doesn't seem to get triggered.

Steps To Reproduce

Steps to reproduce the behavior:

• cargo r --example file_upload
• Click on "Choose Files" (the file input) and select a .txt file -> That works fine but:
• Now click "Clear Files" and drag the same .txt file from Windows Explorer and drop it onto the "Drop files here" area
• Nothing happens!

Expected behavior

It should load the file just like when opening it by clicking on the file input and selecting it through the file dialog.

Screenshots

Environment:

• Dioxus version: latest main branch, commit b20db13e84227b76741e007b2763adc8237ada48
• Rust version: rustc 1.82.0-nightly (8b3870784 2024-08-07)
• OS info: Windows 11
• App platform: desktop

[matthunz]

Thanks for reporting this!

Looks like it is working on MacOS (and no open issues I can see for tao)

[Boscop]

@matthunz Yeah, IIRC I reported an issue with file dropping on Windows when the Tauri project was in early stages, not sure on which repo though, I couldn't find the issue or if it was solved..

EDIT: I think it was this, but it's a different problem: tauri-apps/tao#62

[DogeDark]

I can verify that this does not work on Windows 10, Dioxus main.

[Boscop]

@DogeDark Do you think it's a tao issue?

[DogeDark]

@Boscop I'm unsure. I only tested to verify the issue.

[Boscop]

Apparently it's not a tao/wry issue: tauri-apps/tao#986 (comment)

The tao drag and drop events work just fine on Windows, you can run cargo run --example window and drag a file onto the window, and the event will be logged.
I think dioxus is using wry as well, and in that case you might be looking for docs.rs/wry/latest/wry/struct.WebViewBuilder.html#method.with_drag_drop_handler

So it must be a dioxus issue then..

[DogeDark]

I did some digging and it seems like with_drag_drop_handler blocks the HTML ondrag, ondrop and ondragover events on Windows. If we remove it, our event handlers get called correctly but we rely on with_drag_drop_handler for the file so the app panics. It looks like with_drag_drop_handler has different behavior depending on the platform (or system webview?) since it worked on MacOS.

[Boscop]

@DogeDark Hm, what do you mean by "If we remove it, our event handlers get called correctly but we rely on with_drag_drop_handler for the file so the app panics."?

Shouldn't the HTML drag/drop events be working in conjunction with / backed by with_drag_drop_handler?

[DogeDark]

@Boscop We have a JavaScript shim that is called by Dioxus to create event listeners and when with_drag_drop_handler is used, the JS-native event listeners I mentioned aren't called at all when with_drag_drop_handler is used. The with_drag_drop_handler only sets the latest file(s) that were hovered over the application. Our Rust code that handles the file drop event expects the with_drag_drop_handler to have set a value but it hasn't so it panics.

[Boscop]

@DogeDark

The with_drag_drop_handler only sets the latest file(s) that were hovered over the application.

I found that here

dioxus/packages/desktop/src/webview.rs

Line 233 in 9ffd4b8

let file_drop_handler = {

And about this:

Our Rust code that handles the file drop event expects the with_drag_drop_handler to have set a value but it hasn't

Why doesn't it set the value? :)

[DogeDark]

@Boscop It does, it's just with the drop handler, the HTML events don't get called. Without the drop handler, the HTML events work fine except panics because the drop handler was expected to have set the most recent file:

dioxus/packages/desktop/src/webview.rs

Line 99 in 9ffd4b8

let file_event = recent_file.current().unwrap();

Most likely related: tauri-apps/wry#904

I'm looking into creating a solution.

[Boscop]

Ah..
Thanks for looking into a solution for this :)