You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Since #1187, drag-n-drop is broken on Ubuntu. When a file is dropped onto the window, FileDropEvent::Cancelled is raised instead of the expected DragDropEvent::Drop.
Observe the Terminal output, DragLeave is printed twice, and the view navigates to the dropped file's location.
Expected behavior
A line DragDrop: /path/to/file/dropped should be printed on the Terminal, and the webview should not navigate to the dropped file's path.
Screenshots
Platform and Versions (please complete the following information):
OS: Ubuntu 24.04
Rustc: rustc 1.78.0 (9b00956e5 2024-04-29)
Additional context
I backported the drag-n-drop sample to v0.37.0 before #1187 was merged and added some logs for debugging. Cancelled is unexpectedly raised twice. However, since we did not consider controller.enter() and controller.leave() at that version, it coincidentally produced the expected behavior.
I also noticed that both the current and original implementations intend to use the time parameter to determine the number of drag-leave events. However, in my tests, this parameter was 0 for both occurrences. I am unsure whether this is an issue with my desktop environment or a misunderstanding in the implementation's handling of the time parameter.
UPDATE: I tried version 0.24.0, which uses libwebkit2gtk 4.0 (before the upgrade to 4.1). On Ubuntu 20.04, the time parameter for drag-leave was indeed not 0, which allowed the logic to function correctly. However, starting with Ubuntu 22.04, it consistently passes a time of 0, resulting in the cancelled event being triggered twice.
On Ubuntu 20.04:
On Ubuntu 22.04:
UPDATE2: It indeed appears to be an issue with Wayland. I switched back to Xorg on Ubuntu 22.04 and Ubuntu 24.04 and repeated the test. This time, the drap-leave signal only appeared once and provided the time parameter correctly. Everything worked as expected.
The text was updated successfully, but these errors were encountered:
Describe the bug
Since #1187, drag-n-drop is broken on Ubuntu. When a file is dropped onto the window,
FileDropEvent::Cancelled
is raised instead of the expectedDragDropEvent::Drop
.This seems to be the root cause of tauri-apps/tauri#9725.
Steps To Reproduce
cargo run --example simple
.DragLeave
is printed twice, and the view navigates to the dropped file's location.Expected behavior
A line
DragDrop: /path/to/file/dropped
should be printed on the Terminal, and the webview should not navigate to the dropped file's path.Screenshots
Platform and Versions (please complete the following information):
OS: Ubuntu 24.04
Rustc: rustc 1.78.0 (9b00956e5 2024-04-29)
Additional context
I backported the drag-n-drop sample to v0.37.0 before #1187 was merged and added some logs for debugging.
Cancelled
is unexpectedly raised twice. However, since we did not considercontroller.enter()
andcontroller.leave()
at that version, it coincidentally produced the expected behavior.I also noticed that both the current and original implementations intend to use the time parameter to determine the number of drag-leave events. However, in my tests,
this parameter was 0 for both occurrences. I am unsure whether this is an issue with my desktop environment or a misunderstanding in the implementation's handling of the time parameter.wry/src/webkitgtk/drag_drop.rs
Lines 110 to 115 in daa6136
UPDATE: I tried version 0.24.0, which uses
libwebkit2gtk
4.0 (before the upgrade to 4.1). On Ubuntu 20.04, thetime
parameter fordrag-leave
was indeed not0
, which allowed the logic to function correctly. However, starting with Ubuntu 22.04, it consistently passes atime
of0
, resulting in the cancelled event being triggered twice.On Ubuntu 20.04:
On Ubuntu 22.04:
UPDATE2: It indeed appears to be an issue with Wayland. I switched back to Xorg on Ubuntu 22.04 and Ubuntu 24.04 and repeated the test. This time, the
drap-leave
signal only appeared once and provided the time parameter correctly. Everything worked as expected.The text was updated successfully, but these errors were encountered: