file drag drop along with html drag drop apis

[golden wagon]

Hi,

I know this is currently not possible on v1 or v2, but is there any workaround we can do in rust to just get the file path? The full drag drop functionality is not needed. Any pointers on a hack even would be very helpful

@fresh karma

[golden wagon]

Is there any possible workaround like use both Tauri's file drop feature and HTML5's drag-and-drop by toggling the relevant settings based on the context in which you expect the file drop to occur. This could involve dynamically enabling or disabling Tauri's file drop handling depending on whether the drag operation starts outside or inside the app.

[boreal bone]

Hi, I created a support channel a while ago about this. https://discord.com/channels/616186924390023171/1226450140156661782.

I really feel like this issue is one of the few things that make it hard for people to use tauri. But it isn't really possible. I had one idea (mentioned it in the channel above) but Fabian never responded so idk,

Fabian did mention something about there being a possibility for this to work on linux and macos. #1240051485010558997 message

[golden wagon]

If there is a way to toggle this setting in js during a drag drop at runtime, i was thinking of a work around where on drag over events, if we see a file in the drop targets, then enable the file drop api, else keep it disabled by default

[boreal bone]

Not a bad idea. One issue is that the cursor position isn't tracked when you are dragging a file. So you wouldn't be able still to have a dedicated drop spot

There is also, drag-rs. It is a cool project. Unfortunatly only for V1 and dragging. https://github.com/crabnebula-dev/drag-rs/

[golden wagon]

Jut over the html body, a drag over event whould be able to see if a file is being dragged using pure dom apis

Before being dropped

By default the file drop event being disabled

[boreal bone]

Yeh. So only on the body element. If you wanted it so that a file could only be dropped in a specific section (e.g a folder) than we still have a problem

[golden wagon]

Yeah, we just want it to basically work atleast to start with

Than the current behavior which does nothing

[boreal bone]

Yeh it is better.

[golden wagon]

Maybe @fresh karma can help a bit by answering if this is possible to switch it on/off at runtime

[boreal bone]

Looks like they are onto something... https://github.com/tauri-apps/wry/issues/904

[fresh karma]

This could involve dynamically enabling or disabling Tauri's file drop handling depending on whether the drag operation starts outside or inside the app.
I would imagine that this can only work if the drag operation would be stopped inbetween (which by itself is also not possible)

On windows the gist of tauri's drag drop api is that there's a window on top of the webview that will catch the drag drop window events to be able to get the paths (which is really the only event/api to get them) but the webview does not have a way to let us forward those event to the webview.

Conceptually the same problem if we disable tauri's drag drop impl. Then the webview will receive the events but it has no way to forward those events to us

The new FIleHandle webview2 api is honestly pretty bad for our use case too as it requires explicit handling in js, for example a getPathsForDrop api. It's basically a slightly better alternative to the NewWindowRequested event abuse i mentioned in the other thread, not an alternative to tauri's drag drop apis.
Also it's win10+ only

p.s. in all messages i'm only talking about windows because as mentioned it should be possible on mac/lin (and i was told it's already working by other community members though never tried it myself i think)

[golden wagon]

Thanks for helping with the details 🙂 It looks like then the hack i said above will most likeley not work on windows. I was thinking tauri might be tapping directly into the event loop like in CEF and overriding, but it looks like that is not the case.

For mac/Linux atleast, i will try it out and see how it works. Given the current architecture in windows, i don't see this feature being supported any time soon right @fresh karma

[fresh karma]

I was thinking tauri might be tapping directly into the event loop like in CEF and overriding
Yeah, this is what we want to do but can't.
Given the current architecture in windows, i don't see this feature being supported any time soon right
At least from my understanding, yeah. Maybe a plugin for the aforementioned getter function (win10+ only) but i don't see anything more than that right now.

[half haven]

Hey @fresh karma @golden wagon , if you're wanting to get the full file path using Tauri on Windows I have utilized a little 'hack' in my program.
You can just use the HTML drag & drop, from that event you can get the name, size and last modified date and use that to match it up with any open directories in windows Explorer, and if it exists in any of those folders with the same size and last modified then I guess you can match it. You would also need to account for dragging from desktop (or anywhere else you can drag and drop that is not in explorer) and there is technically the edge case that 2 files in different directories have the same attributes, but if you're okay with those it can work.

Powershell script to get open directories in powershell (change to whatever it would be to get it through winapi)

$shell.Windows() | ForEach-Object {
    if ($_.Document -and $_.Document.Folder) {
        $_.Document.Folder.Self.Path
    }
} ```

*open directories in Windows Explorer I mean

[golden wagon]

Woa neet. That should address most of the use cases i guess. We were also in the way of implementing another way where we planned to use fs access api since its edge webview and it supports drag and drop with fs access apis. The disadvantage being we wont get the full system path, and write access may prompt the user. A hybrid of the above approach and fs access may be quite robust, where we mainly rely on @half haven way and in case of collision, fall back to fs access api, that way correctness is guarteed.

Nice workaround 💥

In Linux and Mac, does tauri's drag and drop interfere with web drag and drop events @fresh karma @half haven

[fresh karma]

I got reports about both (interfering and not interfering) from users but in theory it shouldn't, and if it does then it should be fixable.

[golden wagon]

Hi @fresh karma i enabled tauri file dropped enabled in linux and i am seeing some strange artifacts in linux. The dropped file icon never goes away

anyone seen this before? this is debug build.

if i set the "fileDropEnabled": false flag, the issue is no longer present.

ubuntu 24 os

[fresh karma]

This was not reported before, no.

[boreal bone]

I have experienced things like this before with tauri on windows. The drag would freeze and would leave an artifact of the file. I don't recal much because it was a while ago.

[golden wagon]

I have not yet seen it in windows, but that is conserning. Let me try out different windows 0s just to be sure

[golden wagon]

Looks like a tauri issue.. Also in macos, if file drop event is enabled, the html drop event will be swallowed, the drag and other event gets triggered though

[golden wagon]

Ok, i was able to make it working with both html5 events and tauri file drop events in pure js, taking a page out of taur's overlay implementation in windows @fresh karma @boreal bone

This is the impl: https://github.com/phcode-dev/phoenix/pull/1699

In abstract, with JS API, created a hidden fileDrop window with fileDropEnabled set to true. All app windows has filedrop set to disabled, so html5 drag/drop events will work from app windows

When a dragOver html5 event is detected, we can use tauri APIs to determine the screen bounds of the html element and then reposition the hidden file drop window over that element, and show it.

And when file is dropped over that window, it will emit a tauri event with details about the dropped files, to the actual originator window since there can be multiple windows on the app.

So with this approach, both HTML5 drag/drop and tauri drag drop events work in their own windows and doesnt interfere with the app event handlers.

And it works exactly the same in windows, linux and mac. But in linux we have disabled this due to the above icon ghosting

Now coming to the limitations, The drop UX cannot figure out window occusions and will try to display the drop zone over the top of all windows as it is its own window. I didnt find it too intrusive, or bad per se, but the platform's drop ux may be better. To do that, i think its better for tauri to do something similar in the platform itself @fresh karma