I am also experiencing this same unwanted behaviour with Nautilus on Ubuntu 13.10.

In my case I gave up using Nautilus and had to use Windows Explorer to re-arrange some directories as the auto opening folders made it far more complicated than necessary.

Please can Nautilus be reverted to behave as users expect it.

Please at least change the status of this issue to Confirmed --- I completely vouch for how annoying it is!  How is anyone supposed to drag files around without ending up in some other folder?  At the very least, the hover time needs to be configurable, and at least 1-2 seconds by default; I'd vote for 5 seconds because this really isn't a useful behavior for me, but even 1-2 seconds would at least help most users avoid it except when they really mean to enter the subdirectory.

This behaviour renders nautilus useless to sort a few files in a few different folders by dragging.

As the status of this issue is still unconfirmed I'm raising my voice as well in support of this claim. It has become a real pain to organize lots of files from one folder to a few other folders, a task that I regularly need to perform.

Especially with many files selected I need to be careful to drop them on the right folder, and more often than not, the target folder automatically opens, blocking my workflow.

This bug was opened for Nautilus 3.8 on Ubuntu 13.10, but I wanted to add that it also affects Nautilus 3.10.1 on Ubuntu GNOME 14.04.

I am using 3.12.2-1 in debian testing and can confirm that this auto open behavior is very annoying and painful to the point that I have to use other tools for the task of organizing files. The hover delay before opening a folder is so short that I regularly open folders by accident. I suggest adding a gsettings option to be able to adjust the delay.

I just want to chime in and point out that my favorite distro, CentOS 7, can boast feature parity with Ubuntu on this bug.  Rest assured any Ubuntu users that want to jump over to the CentOS 7 bandwagon will feel right at home with CentOS 7's built in "GNOME nautilus 3.8.2" which has this bug.  :)

It wouldn't be so bad if we at least had a way to turn this auto-hover option off.

And my 2c here too. This bug has forced me to go with an alternative. Add a way to turn this off and it's a feature again.

marked as ui-review to know the reasoning behind it. I think this can be a problem for people with disabilities (or maybe they need anything else anyway, like right click menu instead of dragging).

(In reply to teo from comment #11)
> > I think this can be a problem for people with disabilities
> 
> LOL this is a problem for people without disabilities too.
> Actually who has serious (mental) disabilities is the person who decided
> this it would be good not only as default but as the only option.
> 
> @9 please what was your alternative? Nautilus has become crap, I'd love to
> switch to something decent.

https://wiki.gnome.org/Foundation/CodeOfConduct
This is a warning that no insult is tolerated here or making fun of disabled people.

cc'd Andre

I switched to "nemo" as it doesn't suffer from this design decision.

As I understand it, nemo is a fork from nautilus but before the development moved in a "different" direction.

One suggestion:

1 - User holds a file/folder.

2 - User hover over a folder (nothing should happen, just usual visual guide/confirmation).

3 - User drops the file/folder.

4 - A confirmation dialog (popover?) with three options appear:

[Move file/folder "x" to folder "y" | Enter "x" folder | Cancel move]

4.1 - If "Move": drop file/folder into that folder (without opening it).

4.2 - If "Enter": open that folder and show (unobstrusively, somewhere) two options:

[move file/folder "x" here | Cancel move].

4.3 - If "Cancel": cancel move attempt.

NOTE: A *strong* reason for the "cancel" option is mine personal experience in witnessing huge organization mess that happens when users drag a file/folder unintentionally (because malfunctioning mouse, touchpad bad quality or settings, little skills with touchscreen, disabilities, or whatever reason). They *definitely* don't even know what happened to them, let alone how to fix it.

The cancel option alone is probably reasonable (however it would be good to have a checkbox "don't ask again" and a corresponding setting in Nautilus that allowys you to enable/disable the prompt for confirmation on moving, because most users may be annoyed by a popup when you can just "undo" if you move something by accident), 
BUT the proposal for the dialog for choosing between move and open folder is fundamentally flawed.
IF one chooses to open the folder, s/he's supposed to keep dragging (you may want to drop the item into a subfolder of the folder just opened, recursively). But it is impossible to keep dragging something after having released the mouse button once (how are you supposed to drop the item then?).

The only reasonable way to have the hover-and-open behavior available to the small minority of users who may want it, is to have it as a setting.

Note, by the way, that the hover-and-open behavior MUST anyway have a setting for the time to wait before opening, which it currently lacks. Just implementing it  would already practically fix the bug, because one could just set it to a practically infinite time (which should be the default)

(In reply to teo from comment #15)
> when you can just "undo" if you
> move something by accident), 

My problem with a "heavy dependency" in "undo" is that some *real* users (in some *real* cases) don't even know what was "did". In other words: they will not click "undo", since they don't even know that was made "something wrong". Is smarter to prevent them to make mistakes.

> BUT the proposal for the dialog for choosing between move and open folder is
> fundamentally flawed.

It is not. See below.

> IF one chooses to open the folder, s/he's supposed to keep dragging (you may
> want to drop the item into a subfolder of the folder just opened,
> recursively). But it is impossible to keep dragging something after having
> released the mouse button once (how are you supposed to drop the item then?).

A "move" is *equal* a "cut + paste". So, in my suggestion:

- When used the "move to this folder" option, the app do a "move". Done.

- When used the "enter in this folder" option, the app do a "cut" *AND* FREE THE UI TO *NORMAL* NAVIGATION TO *THEN* just do a "paste" when you inform to it that you are, now, in the desired (sub)folder. Done.

So, in your scenario, you start a "move" action by dragging, but when you drop the file onto a folder, you don't end the move action. Instead, what started as a "move" action is no longer a move action, suddenly becomes a "cut" action, and now you have to do a "paste" separately. Counterintuitive as hell.
And inconsistent with this other case:
you have two Nautilus windows opened and you drag an item from window A to window B, dropping it NOT onto a folder but onto the white background of the window. In that case, the move action that started with dragging ends with dropping (which is the universal convention in every current UI: you move an object by dragging and dropping it). Unless you want to have some counterintuitive popup appear in this case too.

Created attachment 302695 [details]
'Move' mockup

I did a (shameful) mockup to illustrate the steps of the "comment 14". Hope it helps in the understanding of the suggestion.

Note that the UI element [move file 'test.txt' to here] in this "move" workflow can (and should?) be reused for the "cut + paste" workflow.

Created attachment 302697 [details]
'Move' mockup (fixed)

Oops :)

I actually use and like this feature but it depends on the scenario.
It tends to work very well when I'm moving sets of files and I know where the files need to go and the directory structure is known or quite logical and at least a couple of levels deep.
However, when I'm moving files and need a second to look which directory is the right one I need to be very careful about hovering over a wrong directory, or 
I'll might end up entering the wrong one (which means one needs to look for some white space and wait stay there, which doesn't work with list view in a directory with a lot of folders and using the sort directories first option, move the mouse out of the application window, which could set off unintentional drag&drop interaction with another program, keep moving the whole time or cancel the operation by pressing ESC, which doesn't work very well without a keyboard).

I'm not sure how this usability problem could be fixed best (maybe something like a countdown animation, some additional confirmation movement/intercation or hitting a button), but at least users should be able to disable the functionality all together when it doesn't suit them (since this is not very common for file managers AFAIK and does seem to lead to unexpected behavior).

moving files by dragging it to folder, most of the time resulted in wrong target directory.

DIR1/ 
DIR2/ -> DIR3/
File     DIR4/

First case:
I want to move file by dragging to DIR2. While dragging, DIR2 will open and show DIR3 and DIR4. Then I release it, where is the file now? DIR2.. wrong, the file in DIR4 (nautilus open folder below the mouse)

Second case (suppose i like auto open folder on drag :) ):
I want to move file to folder DIR3/. I drag File above DIR2/, wait it to open. Showed DIR3 and DIR4, moving mouse to DIR3.. but oooops DIR4/ opened too quick, the file goes to DIR4 again :)

I hope there is better solution for this

Thanks

Created attachment 310348 [details] [review]
files-view: don't open folder with timer for drag&drop

We were opening the hovered folder after a timeout when performing a
drag and drop operation.
However, this causes that the user could lose track of were the user was
and fail the dnd operation, or even worse, drop in a unknow location and
makes the whole operation rather anoying.
Also looks like could be a problem for disabled people.

So instead just don't open locations on hover for the main view.

Pathbar remains opening with the timer on hover, since the pathbar
itself doesn't change and therefore the user don't lose the track.

As scheduled, pushed for 3.18 release

Attachment 310348 [details] pushed as ec2b967 - files-view: don't open folder with timer for drag&drop

(In reply to Diogo Campos from comment #19)
> Created attachment 302697 [details]
> 'Move' mockup (fixed)
> 
> Oops :)

hey just saw your mockups, when a bug report gets out of topic or there is some personal issue I just stop looking at it, so sorry that I missed your mockups until now that I had to read again the bug report.

For now I think is better to just go with non opening them by default, maybe when we move to action bars (if we think is good) that kind of design will make more sense, but not sure if it would make sense for this specific case anyway.

If you have more design ideas for Nautilus, please feel free to go on IRC gnome-design and propose mockups like that one, thanks!

Second warning. Admin, can you do something about the account of comment #25?
Shouldn't be needed to say but, I don't want to waste nautilus developing time and energy with non-constructive comments with sentences like "finally realize this was an idiotic design" and "have slapped him in the face" referencing people and work of our community.
Thanks :)

And you are also ignoring the constructive part in my previous comment:
- the suggestion of reintroducing the feature as opt-in and configurable
- drawing attention to another issue that is driving the users insane even more than this one did, as discussed in the abovementioned ubuntu bug report

Carlos,
the problem here is that a large number of users DO feel that developers continually slap them in the face with 
1. unwanted changes to UI behaviour that prevent them from using the program as they expect, and
2. what appears as a very arrogant attitude towards users who disagree with the design changes. Did you read that linked ubuntu topic?

As noted above, I felt the need to cease using nautilus due to your design changes.

Ups, seems I didn't cced admins before. Now that are you cced, see my comment #12 and comment #25 for context.
Thanks

General request to any commenters: Please respect https://wiki.gnome.org/Foundation/CodeOfConduct - thank you for keeping Bugzilla a respectful place!

Finally we added a gsetting preference, since some users were using it, but disabling this behaviour by default, 

Still we will like to figure out a good way to navigate while performing dnd, Diogo mockups were on the right direction. I opened bug https://bugzilla.gnome.org/show_bug.cgi?id=754454 for ideas and atached Diogo mockups.
Diogo can you come there??

I messed up sorry, this is the bug report for discussing new ideas: https://bugzilla.gnome.org/show_bug.cgi?id=754455

And these the commits for the gsetting preference:
Revert "files-view: don't open folder with timer for drag&drop"
https://git.gnome.org/browse/nautilus/commit/?id=9b487e890e82419c3b210394bce7d83859864043
dnd: add setting for opening on hover on dnd
https://git.gnome.org/browse/nautilus/commit/?id=2338a9239496b8204d302388649c2b45a57c38e9

(In reply to Carlos Soriano from comment #24)
> hey just saw your mockups

It's OK.



(In reply to Carlos Soriano from comment #32)
> Diogo can you come there??

Sure.

This undesired behavior in Gnome3/Nautilus is still happening.
Ubuntu 16.04

It is a -bad- feature. Usually before letting go of a drag and drop operation, I double confirm to myself that it is really what i want to do.

Gnome3 and Nautilus decide for me that I want to go ahead and actually go into that folder myself, which I did not want to do. I never ever want to move into a folder holding files with my mouse. It's ridiculous, dangerous, and bad protocol from a Window manager. It should do what the user wants and try not to make decisions based on guesses such as "gee, the user is hovering over a folder holding a lot of files, lets just bring them into that folder"

what if i don't _want_ to go into that folder myself? what if I only want to drop files in there?

Please lose this feature, it is the cause of undesired, unrequested behavior. I'm very sorry to say.

this issue is not "fixed" because it's still happening. There needs to be an official update in the repository like every other bug.

hasn't this been an issue for years? When is it going away?

(In reply to reklamchef from comment #35)
> This undesired behavior in Gnome3/Nautilus is still happening.
> Ubuntu 16.04
> 
> It is a -bad- feature. Usually before letting go of a drag and drop
> operation, I double confirm to myself that it is really what i want to do.
> 
> Gnome3 and Nautilus decide for me that I want to go ahead and actually go
> into that folder myself, which I did not want to do. I never ever want to
> move into a folder holding files with my mouse. It's ridiculous, dangerous,
> and bad protocol from a Window manager. It should do what the user wants and
> try not to make decisions based on guesses such as "gee, the user is
> hovering over a folder holding a lot of files, lets just bring them into
> that folder"
> 
> what if i don't _want_ to go into that folder myself? what if I only want to
> drop files in there?
> 
> Please lose this feature, it is the cause of undesired, unrequested
> behavior. I'm very sorry to say.
> 
> this issue is not "fixed" because it's still happening. There needs to be an
> official update in the repository like every other bug.
> 
> hasn't this been an issue for years? When is it going away?

Please don't add more comment if not new info is explained. There is a gsetting to change that, that's why this is "fixed" for now. I hate this as much as you, but we have to take care that lot of users is using it for quite a long time and we don't have a good alternative for it.

What is the gsetting I need to use to change this?  In what version did the gsetting become available?

(In reply to Jim from comment #37)
> What is the gsetting I need to use to change this? 

You can use dconf-editor to inspect the gsettings available.

> In what version did the gsetting become available?

Best to know when an user visible change has been made is to visit the NEWS file: https://git.gnome.org/browse/nautilus/tree/NEWS search for "drag" or something like that.

> What is the gsetting I need to use to change this?  
> In what version did the gsetting become available?

The setting is Off by default (at least that's what the comments in the above linked commits say), so if you are still observing the behavior, as I am, it must mean we still have a version previous to the fix. I guess the fixed version has not made it to Ubuntu yet.

A clarification, it's on by default since https://git.gnome.org/browse/nautilus/commit/?id=16b3460c4b3210574559f9e674e87fed5b6f90af

(In reply to teo89765 from comment #41)
> > A clarification, it's on by default since 
> 
> OMG that's retarded!

Keep the discussion civil.

The decision is that it's not going away until an alternative as good as spring folders is implemented.
If you want it to change, talk with designers for a new proposal and work on it.

Carlos: Please ignore such comments. We've warned already.

Thanks Olav

I don't know why my second comment was deleted. It was perfectly civil and contained a proposal for an actual solution.

> The decision is that it's not going away until an alternative as good
> as spring folders is implemented.

The decision is wrong, but anyway the alternative is easy and obvious:

1. Choose a KEY that will cause to open the folder when hovered while dnd'ing
2. To make this feature discoverable, have a tooltip show up when you drag a
file over a folder, that says something like "Hit the <KEY> key to open this
folder".

Optionally:
3. The setting that currently activates the behavior could still exist, but be
OFF by default, and it would enable the behavior without the need to press any
key, for the sake of those who got used and ended loving the 'feature' (in my
opinion this is unnecessary, as the key is already a good enough alternative;
however, one more option never hurts)
4. if you want users to be able to discover this as well, add information about
this in the abovementioned tooltip. In this case a "don't show me again" option
in the tooltip would probably become necessary.

(In reply to php4fan from comment #46)
> I don't know why my second comment was deleted. It was perfectly civil and
> contained a proposal for an actual solution.
> 
> > The decision is that it's not going away until an alternative as good
> > as spring folders is implemented.
> 
> The decision is wrong, but anyway the alternative is easy and obvious:
> 
> 1. Choose a KEY that will cause to open the folder when hovered while dnd'ing
> 2. To make this feature discoverable, have a tooltip show up when you drag a
> file over a folder, that says something like "Hit the <KEY> key to open this
> folder".
> 
> Optionally:
> 3. The setting that currently activates the behavior could still exist, but
> be
> OFF by default, and it would enable the behavior without the need to press
> any
> key, for the sake of those who got used and ended loving the 'feature' (in my
> opinion this is unnecessary, as the key is already a good enough alternative;
> however, one more option never hurts)
> 4. if you want users to be able to discover this as well, add information
> about
> this in the abovementioned tooltip. In this case a "don't show me again"
> option
> in the tooltip would probably become necessary.

Sounds good, please do as mentioned and discuss it with designers to see if it's a good solution. Until then let's try to keep further comments only adding new info and proposals to avoid spamming all the people subscribed.

> please do as mentioned and discuss it with designers

Where do I reach them?

See https://wiki.gnome.org/Design for contact info