279838 - Feature Request: Lock folders from unintentional drag and drop

Status: NEW

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[Paul McNett]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050123 Firefox/1.0 (Ubuntu) (Ubuntu package 1.0+dfsg.1-2ubuntu3)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050123 Firefox/1.0 (Ubuntu) (Ubuntu package 1.0+dfsg.1-2ubuntu3)

I have lots of IMAP folders and subfolders, and it is just too easy to
accidentally initiate a drag/drop action on a folder, and not realize it until
I've actually moved a folder to an inappropriate place.

I'd like to be able to lock/unlock my folders. When unlocked, I can drag/drop.
When locked, no drag/drop. I see this as an option in Edit|Folder Properties.

Reproducible: Always

Steps to Reproduce:
1. Create some mail folders
2. Note the hierarchy you set up
3. Notice how easy it is to grab a folder and drop it into another folder.

Comment 1

[OstGote!]

xref Bug 210388

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 5

[[:jberkus] Josh Berkus]

Gervase,

I'm voting for this bug.  Both my wife and I have encountered this problem many, many times.  In some cases, this has resulted in permanent loss of mail messages.

Comment 6

[egon stemle]

there exists the 'Disable DragAndDrop' add-on: https://addons.mozilla.org/en-US/firefox/addon/4591 - one might argue that this should be integrated as an option but, still, for your problem it suffices.

Comment 7

[[:jberkus] Josh Berkus]

Egon,

Thanks!

Doesn't help me with 3.0, unfortunately.  Filing a 3.0 bug.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

GTK is constantly thinking I am starting drags when I am not in mozilla apps (generally due to the event thread getting backed up).  I haven't actually gotten burnt by this, but I see how it could happen.

clarkbw, thoughts?  I think one could assert that the number of times someone actually wants to drag-and-drop a folder is low enough that the confirmation dialog requested on (the dupe) bug 488149 is a reasonable and tractable measure.  Not sure the right long-term solution is introducing a 'locked' state though.  On the windows taskbar that felt like a compromise...

Comment 10

[Bryan Clark (DevTools PM) [:clarkbw]]

oh drag and drop, you really do more harm than good.

Moving folders around is likely more of an "organizational mode" than something that is easily and swiftly done as you delete and archive messages.  We could try some kind of a lock mode system, but I'm not sure what good barriers would be.  Do we have a 'locked' state that you have to unlock to start drag and drop?  Or do we have something that catches the first drag and drop of your session and checks that it was your intention?

I'm pretty sure anything is going to be a compromise unless we have some way of detecting an accidental drag & drop.

We might get away with something that holds the first drag & drop of the session for questioning.  (Though session might not be the right time bounding, perhaps it's some kind of auto-lockout after a certain amount of idle time.)

A folder pane before:

+-GMail
|--Inbox
|--Folder 1
|--Folder 2
|--Folder 3

A folder pane after an accidental slip:

+-GMail
|--Inbox
+--Folder 2
//|--Folder 1 //  ( undo move )
|--Folder 3

* Folder 1 is held for some period of time, we'd need to indicate the timeout in the status bar or somewhere we could display it.

There is an issue that we don't have much space in the folder pane to try asking inline questions.  I'd rather not use a dialog that pops up asking a question about your drag&drop behavior.  

This needs more thought, and other ideas.

Also we should make sure that the Activity Manager is showing what folder moves were done, that should at least give an ( undo ) action.  It might also make sense to mark those moves as "Drag & Drop" so you could find the unintentional ones and get rid of them.

Comment 11

[Sergio Villar]

Today I've inadvertently moved an IMAP folder with 24k messages because of drag&drop.

What I suggest, and should be quite easy to implement, is to add a confirmation dialog for this kind of heavy/not-easily-undoable actions.

Comment 13

[Paul McNett]

Hi,

I'm the original reporter of this bug. I've seen it happen at client sites, I've seen family members do it, and I've done it several times over the intervening 8 years.

I initially proposed the locking/unlocking, but no longer like that idea. Here's my user story:

1) Interacting with a folder with 30k messages, system slows for an instant and I wind up dragging the folder to a different folder instead of whatever I was trying to do with the mouse at the time.

2) The individual items are not moved on the IMAP server, but copied and then deleted, one at a time.

3) Thunderbird reindexes.

2.2) In the interim, new mail has arrived on the server and server filter script moves the mail to the old location, which doesn't exist, so the script recreates the missing folder.

2.4) Now, the IMAP server has the original folder in a bogus location, with 30k items, and a new folder with one new item.

I now know that I need to wait it out after mistakenly doing such a drag/drop operation, and then expect to have to manually fiddle with the files/folders on the server side, to get things right again most efficiently.

My new proposed solution:

1) Prompt the user to confirm the drag/drop if the folder isn't empty.

2) (Optional): User preference to override the default prompt-if-not-empty described in 1.

Comment 14

[[:jberkus] Josh Berkus]

You're wasting your time, Paul.  It's pretty clear that there are no resources at Mozilla to even review this bug, let alone work on it.

If anyone can find a TB hacker, I'm all for a kickstarter to get this fixed.

Comment 15

[Paul McNett]

I understand and agree with the concerns about putting up modal confirmation dialogs: there needs to be a really good reason for it. I think we have agreement that there's at least a potential UI problem here, just hesitation on using the blunt instrument of the confirmation dialog to solve it.

I can picture a better UI for it, but it isn't simple to implement:

You basically perform a UI action (drag/drop a folder) and then an icon appears right next to that folder saying something like "click to commit the move of INBOX to Trash". If, and only if, the user does the secondary click on that icon, does the move action actually take place. And, after a certain amount of time, that commit-action icon disappears. Completely modeless, very elegant feeling. But, being more complicated it may never happen.

In any case, I don't think a move of an IMAP folder is cancelable after it's begun, due to synchronization issues between IMAP and Thunderbird and new mail coming in at the same time.

Comment 16

[Brian Hauer]

I like Paul's recommendations here.  Assuming there is ever the developer bandwidth necessary to improve the folder UI, I would like to see any form prevention for of accidental folder moving and a resolution to the vertical gap cited in bug #302109.

Comment 18

[David Chmelik]

Maybe it's my mouse is wearing out, but I'd like this feature for all folders, whether IMAP, or ones with messages you may have saved on your hard disc drive from IMAP or POP.  I've had this problem for years; you'd think it'd be obvious to disable drag & drop for folders.

Comment 19

[[:jberkus] Josh Berkus]

David: check out the extension ConfirmFolderMove.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to [:jberkus] Josh Berkus from comment #19)
> David: check out the extension ConfirmFolderMove.

Thanks for that.  So we have two workarounds
https://addons.mozilla.org/en-US/thunderbird/addon/disable-draganddrop-tb/
https://addons.mozilla.org/en-US/thunderbird/addon/confirmfoldermove/

I'm not sure how I missed it, but there is also bug 467827 describing the same issue.

Comment 22

[kolAflash]

ConfirmFolderMove hasn't been adjusted for Thunderbird-60 and it's development seems dead (last release 2011).
https://addons.mozilla.org/en-US/thunderbird/addon/confirmfoldermove/

So only "Disable DragAndDrop" is left.
https://addons.mozilla.org/en-US/thunderbird/addon/disable-draganddrop-tb/

Comment 23

[Stefan]

I too provide "Disable DragAndDrop" for my users. Unfortunately with Thunderbird currently moving away from XUL overlays, it seems this will no longer be an option.