#[docs] is disable_drag_drop_handler really only for Windows?

25 messages · Page 1 of 1 (latest)

tulip vortex
#

Hello! The below builder fn says it's required for Windows only, but even on macOS this parameter is required to handle drag-n-drop inside HTML, instead of listening for tauri events.
Is the below documentation correct and I miss something? Or should the comment be updated?
Github question: https://github.com/tauri-apps/tauri/issues/11930

/// Disables the drag and drop handler. This is required to use HTML5 drag and drop APIs on the frontend on Windows.
#[must_use]
pub fn disable_drag_drop_handler(mut self) -> Self {
  self.webview_builder = self.webview_builder.disable_drag_drop_handler();
  self
}
GitHub

Hello! The below builder fn says it's required for Windows only, but even on macOS this parameter is required to handle drag-n-drop inside HTML, instead of listening for tauri events. Is the be...

stiff ruin
#

let's keep it on discord.

tulip vortex
#

@stiff ruin thanks for your reply! You actually responded on Github but if you prefer, we can chat here. I will try to reproduce it better, but according to your comment, I should be able to use "drag" events inside HTML on macOS WITHOUT setting any flags to the window etc?

To me it looked logical that you either intercept events on Tauri level from a window, OR you can access the events on macOS.

What would be the most reliable way to implement it once for macOS, Windows and Linux? I just want to always properly catch events because it's an important feature to me.

tulip vortex
#

So I checked once again: without using .disable_drag_drop_handler(), HTML callbacks for onDragOver and onDrop are not being triggered

#

Without understanding how to reliably enable handling the drag'n'drop inside HTML, seems like the best option is gonna be to handle it using the window events.
Much less convenient (with calculation the target view where drop happened) but reliability matters more.

Please let me know if there's a way to make HTML onDrop & onDragOver work reliably on Windows+macOS+Ubuntu 🙏

I use the latest version of Tauri

stiff ruin
#

ahh oh my god. i meant "let's keep it on github" 😂

#

that's why i marked it as solved

#

anyway, let's keep it on discord then kkushKEKW

tulip vortex
#

no problem 🫡 thanks for spending your time maintaining the open source project!

#

whatever is more convenient for you

stiff ruin
#

both is fine for me. if the same question is asked on discord and github i just tend to close the discord one in favor of the gh issue for visibility or whatever. but i feel more at home on discord so all good

#

First for your own use-case. Do you need the file paths of the dropped paths? If not, i'd always recommend to disable tauri's file drop and use the webview/browser native stuff.
If you do need the file paths you must use tauri's file drop (== don't call disable_file_drop_handler)

tulip vortex
#

ok here I can see you typing and react quicker 😹
I will post the resolution (if any) on Github for visibility and close the issue (and will consider it a contribution :kekw:)

#

Do you need the file paths of the dropped paths?
Yes, in fact, I only need the file path

#

hmm, why the file path won't be available in web events?
permissions, I assume?

stiff ruin
#

okay, this together with needing Windows support already rules out the native events

stiff ruin
tulip vortex
#

By native events you mean HTML events?

stiff ruin
#

yea

#

shouldn't call them native since the tauri ones are "more native" x)

tulip vortex
#

and to close it completely — is it 100% reliable to use the tauri events?
is there anything that can make them behave weird (at least known)?
it must work, any inconveniences are solvable

#

example is coordinates shift because of devtools, but that's fine as long as it works in release

stiff ruin
#

can't think of anything. afaik they work pretty well. except for another offset in the size of the titlebar on macos. This one is considered a bug we'll fix though (in contrast to the devtools one we probably can't fix)

tulip vortex
#

is there a workaround for this bug?
I create the main window in rust and use transparent titlebar with my custom colors

stiff ruin
#

not aware of one right now. but if you don't use the native titlebar it may not be an issue for your app