User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 MailNews does not confirm folder moves. This is particularly bad because it is easy to accidentally move a folder. If you're like me and have very large folders, this is quite destructive because it takes forever. Even if your mouse is not on top of the folder name, if it is in the same row as the name you may still accidentally rename a folder when you intended to grab the scrollbar. This is particularly true for those of us with imperfect motor control. Reproducible: Always Steps to Reproduce: 1. Click left mouse button directly to the left of the scrollbar 2. Move mouse up or down 3. Unclick Actual Results: You moved a folder. Expected Results: Either one of two things: 1. confirm folder moves (easy and not all that painful as you don't go moving folders every day). 2. require the mouse to be on top of the folder name. I don't know how easy this is, but if a folder name is big, it might not be an effective solution anyway. This is an annoyance that's been plaguing me for some time. Any help would sure be appreciated.

IMHO dupe of Bug 224393.

For tracking purposes one generally wants to dup the newer bug, but the two bugs are duplicates. Perhaps dupe the other?

*** Bug 224393 has been marked as a duplicate of this bug. ***

(In reply to comment #0) > 1. confirm folder moves (easy and not all that painful as you > don't go moving folders every day). Good idea ... though I'm inclined that this should be a pref. > 2. require the mouse to be on top of the folder name. I don't > know how easy this is, but if a folder name is big, it might not be > an effective solution anyway. Hmm....

*** Bug 238774 has been marked as a duplicate of this bug. ***

The current awful behavior matches Netscape 4. Folders easily get lost this way, and the filters using them can break. :-(

(In reply to comment #6) Actually, the filters should update automatically. However, the bug is quite annoying, even so.

*** Bug 251700 has been marked as a duplicate of this bug. ***

I woul prefer it you should click on the folder icon or (optional) on its name to move the folder. I think this would avoid 95% times this bug.

This probably should have been moved to TB a while ago.

This problem carries over from Netscape 4. There's no reason for it to be TB only. All three dupes, and this, were filed against Seamonkey, assuming the UA string in each bug is correct.

*** Bug 222140 has been marked as a duplicate of this bug. ***

This bug drives me crazy as I have several subfolders with their own subfolders that can contain more than 7000 emails at a time, and when you select a folder too quickly, sometimes a folder is dragged into a different subfolder without you even selecting one. I find that it's almost always random, and only vaguely follows the path of my mouse after I released the mouse button when I selected a folder. Then you have to wait for 3-5 minutes for the folder to be moved and then again to move it back where it was. This happens to me at least 3 times a day. Resolution: Add a confirmation window that says "Are you sure you want to move this folder? Cancel/OK" that has a "do not show this again" checkbox for those who would be annoyed by it. It can also be added in the Prefs so that if someone unchecks the box, they can reactivate the option later in that starts happening to them. It would save me a lot of time and frustration!

See also Core bug 167404.

Is there any way to get movement on this bug? A simple confirmation dialog box would really do the trick. If I had guidance on how to bring up such a box I might try the code myself.

Someone should probably point out this extension (Confirm Folder Move): https://addons.mozilla.org/en-US/thunderbird/addon/2152

So where is the TB version of this bug? The folder panes have separate code these days in SM and TB.

I haven't created one. Should I, or is there a way to mark this for both?

Maybe search for a more generic DND bug first and if found create a dependancy. I have the problem in bookmarks management too, where there are a lot more folders to lose things in.

(In reply to :aceman from comment #17) > So where is the TB version of this bug? That would be bug 467827 and bug 279838