elementary
Drag and drop files into a folder doesn't always work
What Happened?
Drag and drop more than one file will fail to move them 50% of the time.
Drag and drop one file into a folder ~always works.~ EDIT: actually, it's failing too.
https://github.com/user-attachments/assets/d15a185b-f6be-4886-b54e-2666d12bbc66
Steps to Reproduce
- Select some files.
- Drag them over a folder icon and immediately drop them there (the first attempt should often fail).
- Select the files again.
- Drag them over a folder icon and hold still until that folder is opened, then drop the files in there (it should often fail too).
Expected Behavior
Drag and drop ~for multiple~ selected files should work. ~the same as it does for a single file~
OS Version
8.x (Circe)
OS Architecture
amd64 (on most hardwares)
Session Type
Secure Session (Wayland)
Software Version
Latest release (I have run all updates)
Log Output
Hardware Info
No response
Sounds like a recurrence of #2419 except I think that applied to all occasions. If it only happens sometimes it would help to identify the conditions. For example, are there any unusual characters in the filenames? Make sure you have v7.1.6 as some DnD related fixes were applied there.
I have 7.1.6.
In the screen recording I used some empty files named "test file" and "test file 2" — only spaces, no special characters or accented letters.
I repeat the same operation on the same files, and it works 50% of the time.
Hmm, cannot reproduce with main at the moment. Could you try running io.elementary.files in a terminal to see whether and error messages are produced when the move fails?
Are you copying or moving the files? They should move by default but I cannot see how the moved single file is returning to the original position after you select it- are you pressing <Control>Z or Cut/paste?
Does the issue still occur if you allow the destination to auto-open before dropping?
Are you copying or moving the files? They should move by default but I cannot see how the moved single file is returning to the original position after you select it- are you pressing
<Control>Zor Cut/paste?
it happens for us without pressing anything
Does the issue still occur if you allow the destination to auto-open before dropping?
Yes. It just has the icon do the phantomatic-woosh-back-to-initial-spot all the same but nothing is transferred
console isnt helpful either. Bug reproduced like ten times, this is all what is in it (only those two warnings nothing else)
`** (io.elementary.files:16829): WARNING **: 20:57:13.269: AbstractDirectoryView.vala:3341: Name unchanged
** (io.elementary.files:16829): WARNING **: 20:57:51.794: OverlayBar.vala:298: Error loading image resolution in OverlayBar: Format der Bilddatei unbekannt
`
OK, thanks. The first error "Name unchanged" is surprising as the file is not ostensibly being renamed so could be a clue.
console isnt helpful either. Bug reproduced like ten times, this is all what is in it (only those two warnings nothing else)
Maybe running G_MESSAGES_DEBUG=all io.elementary.files will provide more info on why the drop was rejected?
console isnt helpful either. Bug reproduced like ten times, this is all what is in it (only those two warnings nothing else)
Maybe running
G_MESSAGES_DEBUG=all io.elementary.fileswill provide more info on why the drop was rejected?
This one shows up when attempting drag, with or without success:
** (io.elementary.files:52765): DEBUG: 23:41:06.011: DndHandler.vala:283: DNDHANDLER selection data is uri list returning true
if it succeed, the following shows up, twice in each instance (said url is of the file that was moved):
** (io.elementary.files:52765): DEBUG: 23:42:44.259: File.vala:565: Enthaltender Einhängepunkt für Datei /home/teamcons/Downloads/Namenloser Ordner 2/Namenloser Ordner/Namenloser Ordner/Namenloser Ordner/577047274_1408924247910276_7931132753181981938_n.jpg wurde nicht gefunden
"Containing attachment point for file [bigass url] could not be found"
nothing else shows up if fail
Are you copying or moving the files? They should move by default but I cannot see how the moved single file is returning to the original position after you select it- are you pressing
<Control>Zor Cut/paste?
I was moving the files. In the screen recording I was using Ctrl + x to cut and Ctrl + v to paste. I forgot that using Ctrl + z to undo the last operation is a lot faster.
Does the issue still occur if you allow the destination to auto-open before dropping?
From a quick test I just made, no it doesn't. It seems to happen only when you drop the files over the folder icon. EDIT: actually, it started happening in that case too.
Here's the full debug output while reproducing the problem:
Also, I just noticed that, in rare occasions, dragging a single file fails the same way.
@o-alquimista Thanks for the extra info. Unfortunately the debug messages do not seem any different to mine and I am not experiencing the bug. I may have to push a branch with extra debug messages in the DnD code that you could try. I assume the function file_accepts_drop () is returning false for some reason but there are no debug messages there 😞
I've updated the issue to inform that now I'm reproducing this more often for single-file drag, and even when I let the folder under the cursor auto-open before dropping. It's so bad I'm using keyboard shortcuts only.
It doesn't look like a mouse problem, because the drag is not accidentally interrupted. The dragged files, when dropped, show an animation as if they were returning to their original place; it's the same animation that you get when you drop a file over an invalid area like the desktop wallpaper — the action is rejected.
In case it matters, here's my hardware info:
- Mouse: Razer Deathadder v2 Mini
- Monitor: LG ultrawide FHD, resolution 2560x1080, 75hz.
- GPU: AMD Radeon RX 6600