Dragging and dropping file in same folder should not create link

[kdwk]

What Happened

When dragging and dropping a file within the same folder, a symlink should not be created. Most of the time, I dragged the file by mistake and found no convenient way of canceling the action short of dragging the file out of the window, which is not an elegant solution. Less advanced users may also mistake the file for a duplicate and accidentally delete the original file.

Expected Behavior

If a file is dragged and dropped into the same folder, the action should be ignored.

Steps to Reproduce

1. Drag a file
2. Drop it into the same folder

Logs

Platform Information

[jeremypw]

I am not sure doing nothing is the correct behaviour - it depends what the typical user would expect to happen if they drag and drop into the same folder. The two possible results are a link or a copy. If the user intention is not clear then perhaps it would be better to show a list of options (including cancel). I have a feeling Files used to do this with a secondary button drag (or was it <Control>Drag?) but this seems to have changed.

Needs UX team input.

[pedropaulosuzuki]

Can confirm on elementaryOS 6.0 Odin. Expected behavior: nothing should happen. I wouldn't want to create a link or to create an accidental copy just for dragging a file inside the file explorer itself.

[o-alquimista]

On GNOME Files you can abort a drag operation by pressing ESC once, but this doesn't currently work on elementary. What do you think?

UPDATE: strange, now the ESC thing is working. It wasn't working a minute ago.

UPDATE 2: ESC stopped working again.

[jeremypw]

My preference would be to always ask what action is intended when dropping a file onto its parent folder.

[janxkoci]

Esc to cancel the drag doesn't work for me for quite a while. It's annoying.

[jeremypw]

@janxkoci Esc to cancel drag works for me on version 6.5.0 (press Esc while continuing to hold down the primary button). Alternatively just drop onto an inactive area out of the window.

I think this is something implemented by Gtk anyway not Files.

[janxkoci]

@jeremypw Nope, dragging and pressing Esc still creates a link even under version 6.5.0. Just tested it fresh after reboot. The Esc does interrupt the dragging though, but link is still created.

[jeremypw]

@janxkoci Could you try dragging something in e.g. Code and see whether pressing Esc (before dropping) cancels the drag? I am fairly sure this behaviour is handled by Gtk.

[janxkoci]

@jeremypw Dragging selected text in Code and pressing Esc will move the text to wherever the cursor is in that moment.

[jeremypw]

@janxkoci This confirms that it not specifically a Files problem then, it is something to do with the underlying setup. Maybe something to do with the keyboard layout or locale? Are there any accessibility features enabled related to keyboard? Are you using an input engine? Any customised shortcuts involving Esc? Is Esc working normally for things like dismissing the App menu or other winganel dropdowns? Could you confirm which version of Elementary you are running? I assume Horus if you have Files 6.5.0.

[janxkoci]

Sorry for late reply, I was busy.

Maybe something to do with the keyboard layout or locale?

I don't know, I'm just using Czech layout. It's quite fragile though - just opening settings and looking for answers to the questions made it switch to another layout (I suspect US English). 🤷 (PS: I also suspect this is related to iBus, as it's introduction made my layout settings generally weird.)

Are there any accessibility features enabled related to keyboard?

Not that I know of.

Are you using an input engine?

I don't know what that is.

Any customised shortcuts involving Esc?

Nope.

Is Esc working normally for things like dismissing the App menu or other winganel dropdowns?

Yes, it works as expected.

Could you confirm which version of Elementary you are running? I assume Horus if you have Files 6.5.0.

Yep, OS 7.

[jeremypw]

Are you using an input engine?

I don't know what that is.

An input engine is something that works with IBus like Anthy of Mozc to assist the input of certain languages. They appear in Keyboard settings under the "Input Method" tab, in the sidebar.

I've tried to reproduce this with a Czech layout and with a Czech QWERTY input engine selected but without luck.

[janxkoci]

FWIW I use Czech QWERTZ layout. Anything else I can test?

They appear in Keyboard settings under the "Input Method" tab, in the sidebar.

The sidebar is empty, but in the indicator I see this weird thing:

Since the "Input method" interface was introduced (using iBus) I experience all kinds of weird issues (e.g. elementary/switchboard-plug-keyboard#355).

[jeremypw]

Looks like you are not using an input engine (none installed) but you do have a wingpanel keyboard indicator and you do have "Input Method" (vstupni metoda) switched on. If you are using a physical Czech keyboard then you should not need this switch on. It is also weird that you have a wingpanel indicator at all since with only one input option it should not show. I think QWERTY in English == QWERTZ in Czech since the Y key in the former is replaced by a Z key in the latter. I have now also tried using Czech with <|> key and also the Ibus Czech input engine but still could not reproduce the issue.

You could try running sudo showkey -a in a terminal. This shows the keycodes and scancodes (and ascii interpretation) of each key press and release (see https://www.geeksforgeeks.org/showkey-command-in-linux-with-examples/).

On my machine I get for Esc

^[ 	 27 0033 0x1b

[janxkoci]

As I said - weird issues 😅

The showkey command output looks the same on my end.

[jeremypw]

I'm pretty much out of ideas at the moment. You should open a new issue at https://github.com/elementary/triage/issues as this issue is not related to the original report nor limited to Files and I am not sure which project is most appropriate (could even be an upstream issue).

[jeremypw]

@danirabbit Are you happy with the current behaviour of Files when dropping a file into the same folder (with no modifiers) or should it be changed?

[danirabbit]

@jeremypw I think I agree with the OP that it should just cancel if the destination folder is the same as the source folder.

I can see the utility in creating a symlink for specific development tasks, but it sounds like the feedback we're getting is that this behavior feels non-deterministic for most folks.

I don't really think adding a dialog or some other choice mechanism here would be an improvement. It feels more complicated to do a symlink in that way than it would be to use the context menu, so I can't see that being someone's preferred or intended workflow.

Since we have explicit actions for copy and symlinking, this is probably a case of trying to be too clever. It sounds like the most predictable thing to do is to cancel

[jeremypw]

OK - that's easily done and makes sense.