Open Bug 812920 Opened 12 years ago Updated 2 years ago

Dragging a folder to another account, without ctrl, copies it instead of moving it. And drag cursor indicator is incorrect.

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Version:
16 Branch
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

People

(Reporter: matteosistisette, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 Steps to reproduce: Clicked on a folder (a subfolder of the Inbox folder of an account) and dragged into another folder (a subfolder in my Local Folders). That is, move a whole folder from a place to another. The folder contains as little as 3003 messages. Actual results: More than half an hour has passed and it it still working. The hard disk is crunching and Thunderbird is unresponsive. Expected results: Moving a folder should be very fast even if the folder is huge and contains a lot of messages. I can understand the slowness of moving a block of messages from a folder to another, because it is a lot of text processing. But moving a whole folder should be just a matter of physically moving a file or two in the filesystem. If it is not, then something is badly designed.
Oh, now I see. The folder was COPIED instead of moved. That's the problem. I guess the same kind of logic is applied to when you drag and drop folders in the filesystem. (If the source and target location are on the same physical filesystem the folder or file is moved, otherwise it is copied). So here if you drag and drop into the same account it is moved, but to another account or to/from local folders then it is copied. That makes kind of sense but is not obvious at all, so it MUST at least show a "+" icon near to the cursor when you are dragging to copy, so that you know that this will do a copy and not a move. Also, I now notice that this doesn't apply to message, so this is completely inconsistent and this inconsistency must be fixed. I also dragged and dropped a bunch of MESSAGES from a folder (inside the inbox of an account) to another (inside a folder in Local Folders) and in that case, the messages were MOVED, not copied. So the same behavior must be applied to both folders and messages.
Actually, when you ctrl+drag a folder it does show a "+", meaning you are copying, but when you just drag, it shows an arrow, MEANING you are moving, but then it copies instead, so it simply and plainly does the wrong action, despite of what it "promises".
Summary: Moving a folder is terribly slow → Dragging a folder copies it instead of moving it, despite what the cursor indicates
likely duplicate, but I didn't find it on a quick look
Whiteboard: [dupeme?]
(In reply to matteo sisti sette from comment #2) > Actually, when you ctrl+drag a folder it does show a "+", meaning you are > copying, but when you just drag, it shows an arrow, MEANING you are moving, > but then it copies instead, so it simply and plainly does the wrong action, > despite of what it "promises". this really seems unlikely to be caused by Thunderbird. Perhaps it never got the "ctrl" modifier. Can you reproduce with some other application, or in compose by selecting some text and ctrl+drag? If it fails, does this reproduce in safe mode with a newer version?
Flags: needinfo?(matteosistisette)
The problem is not with ctrl. The behavior with ctrl is the expected one. The problem is when you drag and drop WITHOUT ctrl: dragging and dropping is universally known to mean "move"; instead TB copies the messages. It MAY be true that TB doesn't get the ctrl modifier (in which case, once this bug is fixed, TB will always move messages and never copy them) but we'll never know while the default behavior is to copy
Flags: needinfo?(matteosistisette)
(replace the word "messages" with "folder" in my previous comment)
sorry matteo, my bad. I let comment mislead me. so you can reproduce this always, at will?
Ok, I've tested again. Forget everything and let's start from scratch. Drag a folder from its place to another place within the same account => the cursor looks like an arrow while you drag, and the folder is moved. OK Ctrl+Drag a folder from anywhere and drag it to anywhere => the cursor has a "+" symbol and the folder is copied. OK Now Drag a folder (without Ctrl) from its place into another which belongs to ANOTHER account, or from an account to somewhere within Local Folders, or viceversa => OBSERVED BEHAVIOR the cursor looks like an arrow, as if the folder was going to be moved, but it is copied instead => EXPECTED BEHAVIOR EITHER the cursor should have a "+" indicating you're copying and then the folder would be copied (it makes sense to copy rather than move because it is between different accounts) OR the folder should be moved if the cursor remains like an arrow. The bottom line is that WHENEVER drag&drop results in copying, the cursor MUST have a "+" sign. Whether to move or copy by default depending on whether or not source and target are on the same account is questionable and different behaviors can be OK; but if drag&drop result in copying and you don't see a "+" cursor, that's wrong. Additional issue: Ctrl+Drag a folder from an account to another: =>OBSERVED: the cursor does have a "+" and the folder is copied; this is OK (meaning what you see is what you get) but the issue is that there is currently NO WAY to move a folder from an account to another (or from an account to local folders or viceversa) rather than copying it. So it would be preferrable to have drag&drop ALWAYS result in moving and Ctrl+Drag&drop ALWAYS result in copying (and the cursor reflect that). So, to sum up: - unquestionable bug: the cursor doesn't always reflect what's happening (it does not show a "+" when you are actually copying, if you drag&drop to a different account) - design issue or lack of obvious feature: there is no way to move a folder from an account to another: you have to copy and then delete the original one (I'm talking only about pop3 accounts, no imap).
christian, can you reproduce this?
Flags: needinfo?(chriechers)
Yes, I can confirm the behavior as described in comment 8.
Flags: needinfo?(chriechers)
matteo, do you know how it behaved prior to version 16? fwiw on windows, my drag from imap folder to Thunderbird gmail imap account failed.
Status: UNCONFIRMED → NEW
Component: Untriaged → Folder and Message Lists
Ever confirmed: true
Summary: Dragging a folder copies it instead of moving it, despite what the cursor indicates → Dragging a folder to another account, without ctrl, copies it instead of moving it. And drag cursor indicator is incorrect.
Whiteboard: [dupeme?]
my drag from imap folder to Thunderbird gmail imap account failed ... without error
(In reply to matteo sisti sette from comment #5) > The problem is when you drag and drop WITHOUT ctrl: dragging and dropping is > universally known to mean "move"; instead TB copies the messages. Following is help content of SeaMonkey which is inherited from Mozilla App Suite <- Mozilla <- NetScape. > Moving or Copying a Folder > > You can copy a folder and its contents to another mail account, or move a > folder within the same mail account. > > To move or copy a folder, begin from the Mail window: > > > Select the folder you want to move or copy. > Do one of the following: > > To move the folder under another folder within the same account, drag > the folder over the name of the other folder. The folder you moved > becomes a subfolder of the other folder. > To copy the folder to another account, drag the folder over the name > of another account. > To copy the folder under another folder in another account, drag the > folder over the name of another folder in another account. The folder > you copied becomes a subfolder of the other folder. As wriiten in the help, "drag&drop folder between two accounts" == "copy folder to different account" always, and is not altered. This is same as "drag&drop of file/folder between two different drives on Mac". In NetScape/Mozilla/Mozilla App Suite/SeaMonkey/Thunderbird", "an account" can be IMAP account. So "drag&drop folder between two accounts" was defaulted as ""copy folder" and it is kept. Both are for "safety". See problem like comment #12, please. Unfortune is; "Icon upon dragover at droppable folder" is controlled by "folder pane" process based on keyboard modifier. Tb's dragover event handler merely returns droppable or not. But actual copy/move operation is done by "Copy/Move folder" process. When "CTRL+Drag of folder" was supported at folder pane by Mozilla family, "CTRL+Drag of folder between accounts" correctly showed "+" upon dragover, unfortunately. :-) Similar "mismatch between Folder pane process and actual Folder handling proccess" is al so seen in following cases. - "Shift+Drag of folder between accounts" is also supported at folder pane, and it doesn't show "+", unfortunately, according to "Shift + dragging and dropping is universally known to mean move". However, IIUC, "Move folder between accounts by Drag&Drop" is not supported by Folder handling code. - "Multiple folder selection at folder pane" and "Drag of the selected multiple folders & Dragover on a folder at folder pane" is supporte by Folder pane process. However, "copy of multiple folders at same by drag&drop" is not supported yet by Folder handling code. Which is request of this bug? (a) Change "drag&drop folder between two accounts" to "move folder to different account", because dragging and dropping is universally known to mean "move". (b) Show "+" correctly when "drag&drop folder between two accounts", as done in Ctrl+Drag. If (b), it may be simple. droppable or not is determined by canDrop handler which is saved in gFolderTreeView.canDrop. Currently used module source is following. > http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#1365 "drag folder between accounts" can be checked in canDrop handler. Can "canDrop handler" alter icon shown by folder pane code upon dragover event?
Sorry, that code was canDrop of thread pane. canDrop of folder pane is; http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#487
canDrop: function ftv_canDrop(aRow, aOrientation) has following logic. > 525 // Don't copy within same server. > 526 if ((folder.server == targetFolder.server) && > 527 (dt.dropEffect == 'copy')) > 528 return false; dt.dropEffect == 'copy' is perhaps set when "CTRL+Drag". So, adding steps like following can be a solution of this bug. // Change icon to "+" if Drag folder between accounts if ( folder.server != targetFolder.server && ( dt.dropEffect != 'copy' || dt.dropEffect == 'move type because of Shift+Drag' ) ) { Request icon change, or change dt.dropEffect to 'move type or non-copy' if possible; return true; } If dt.dropEffect is different among Drag, CTRL+Drag, and Shift+Drag, "Shift+Drag of folder between accounts" is easily rejected by following. if (folder.server!=targetFolder.server && dt.dropEffect==Shift+Drag type) return false; "Drag of multiple folders to folder" can be rejected by; if ( Selection upon dragstart is multiple folders at folder pane ) return false; By the way, I think there is no reason to reject "CTRL+Drag(copy) single folder to different parent of same account", because user intentionally executed "CTRL+Drag" so user actually wants to do "Copy folder", and because difference between Drag, CTRL+Drag, Shift+Drag can be easily known via dt.dropEffect by FolderTreeView implemetation or improvements. What is reason to ignore "Shift+Drag(move) single folder to different folder" request even though dt.dropEffect is availabl and can be used? Why "Copy folder within same account by Drag" is rejected?
dropEffect is defined at; > http://mxr.mozilla.org/comm-central/source/mozilla/dom/interfaces/events/nsIDOMDataTransfer.idl#41 > 12 interface nsIDOMDataTransfer : nsISupports > 41 attribute DOMString dropEffect; > 42 > 43 /* > 44 * Specifies the effects that are allowed for this drag. You may set this in > 45 * the dragstart event to set the desired effects for the source, and within > 46 * the dragenter and dragover events to set the desired effects for the > 47 * target. The value is not used for other events. > 48 * > 49 * Possible values: > 50 * copy - a copy of the source item is made at the new location > 51 * move - an item is moved to a new location > 52 * link - a link is established to the source at the new location > 53 * copyLink, copyMove, linkMove, all - combinations of the above > 54 * none - the item may not be dropped > 55 * uninitialized - the default value when the effect has not been set, > 56 * equivalent to all. > 57 * > 58 * Assigning any other value has no effect and retains the old value. > 59 */ Because aEvent.dataTransfer is saved in "this"(folder tree row, or cell) by _onDragOver handler, content of aEvent.dataTransfer can be checked by canDrop handler. > http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#703 > 703 _onDragOver: function ftv_onDragOver(aEvent) { > 704 this._currentTransfer = aEvent.dataTransfer; > 705 }, However, in folder tree view, this._currentTransfer.dropEffect (=aEvent.dataTransfer.dropEffect) == "move" was passed to canDrop handler from tree view processor of Tb 24.1.1 when "Drog without Shift key pressed"(I expected "uninitialized", but it wasn't). So, "saving aEvent.shiftKey, aEvent.ctrlKey etc.(or entire aEvent object) in this object by _onDragOver handler" is additionally needed to know "Drag with no modifier" or "Drag with Shift key". Because canDrop is called three times for a tree row(a folder) in folder pane, with aOrientation=-1(BEFORE, first 1/4 of row height), 0(ON, mid 1/2 of row height), or 1(AFTER, last 1/4 of row height), if icon change is possible, icon change should be done when aOrientation=-1, and icon change should be reset when aOrientation=1.
Permitted aEvent.dataTransfer.dropEffect value looks passed in aEvent.dataTransfer.allowedEffecte(if Drag of folder with no modifier, with ctrlKey, with shiftKey), allowedEffect="copyMove" looks always set. I think any of "copy", "move", "copyMove" can be set in aEvent.dataTransfer.dropEffect in this case. Because dropEffect is a property of event object which is passed to event handler from tree view processor, modified aEvent.dataTransfer.dropEffect value should be set by event handler who was passed the event object. So, it may be impossible to pass the modified dropEffect value to tree view processor in gFolderTreeView.canDrop(aRow,aOrientation) nor gFolderTreeView.drop(aRow,aOrientation). This should be perhaps executed by gFolderTreeView._onDragOver event handler to whom event object is passed from tree view processor. When, how, by whom, is gFolderTreeView.canDrop and gFolderTreeView.drop called? If it's by event handler of folder tree view, returning modified aEvent.dataTransfer.dropEffect to tree view processor is perhaps simple job. However, if not, it may be hard job...
Blocks: 375071
Depends on: 319743

This issue (and most others that are mentioned as "blocks" or "depends") has existed for almost a decade and I am at a loss as to why something which would be expected as normal behavior, is simple to both understand (and implement-see below), and is needed....has nevertheless sat in limbo this long. I would like to summarize the situation and propose/ask a solution:

SUMMARY: this is an issue with the moving/copying of messages and folders between accounts not working properly and as expected.

A user of Thunderbird has multiple/different accounts. At a minimum a user with one email has that email as an account, but also has 'local folders' as a 2nd 'account'. If they have more email addresses those too are also accounts visible in the left pane. Of course each account will tend to naturally have folders - we all use them.

Right now the moving/copying of individual MESSAGES (one or multiple; and via mouse - i will not discuss right clicking or key shortcuts which are other tickets and issues) works as expected in all possible variations. Let us summarize what that is:

  1. If you select (one or more) messages and drag to another folder in the same account, they are moved. Correct.
  2. If you drag while holding CTRL (still same account) the cursor turns to [+] and the message(s) will copy. Correct
  3. If you drag to a folder in a DIFFERENT account, they will MOVE. Correct.
  4. If you drag while holding CTRL (DIFFERENT account), the cursor turns to [+] and they copy. Correct.

This is pretty much how everything else works on all modern computers for years. Great.
Now let's cover folders instead of individual messages where things break:

  1. Select a folder and drag to another location in the SAME ACCOUNT. Folder moves. Correct.
  2. Drag folder (still same account) but hold CTRL. The cursor changes to a circle/slash indicating copy not permitted. This is different behavior (not allowing copy) since messages can be copied (why not folders too?), but at least it is communicated properly to the user. ACCEPTABLE
  3. Drag a folder from one account to a DIFFERENT account. Cursor looks normal (no [+] indication which would indicate copy), yet the folder is COPIED instead of moved. BROKEN BEHAVIOR.
  4. Drag a folder from one account to a different account and hold CTRL. Cursor turns to [+] and the folder will copy. CORRECT.

The folder should have moved to the new location, not made a copy. And if move is not permitted then cursor should have turned to circle/slash (or changed to [+]

PROBLEM SUMMARY: user can move one or more messages (drag and drop with mouse) from one account to another along with correct cursor[+]/CTRL functionality. However moving a folder in the same manner (which is nothing more than just a list of messages) results in a copy and with broken cursor[+]/CTRL functionality (since the cursor indicates a move by not diplaying a [+] even though CTRL is not being pressed.)

I then read various 'blocks' and 'depends' tickets (one goes back 17 years! another 15yrs!!). I don't understand the difficulty or delay fixing this issue because there is no significant grand issue to moving a folder WHEN INDIVIDUAL MESSAGES ARE ALREADY PERMITTED TO MOVE. A folder is just a collection of messages. If the messages individually can move, then so can the folder!

I mean this in the following sense:
IF individual messages can be movedfrom AccountA:FolderA to AccountB:FolderB, then folder move of AccountA:FolderA to AccountB can be implmented easily with existing Thunderbird functionality. Why not this?:

DEFINE FUNCTION to "move AccountA:FolderA to AccountB"

CREATE NEW(empty) FolderB on AccountB (give same name as FolderA)
FOR EACH message X in AccountA:FolderA:
MOVE message X to AccountB:FolderB
DELETE AccountA:FolderA (which is now empty)

RESULT: folder and all messages moved using existing simple/permitted thunderbird operations.
Behavior works as expected and allows folders to move just like messages.

Can this be done? Are all of the 'blocks' and 'depends' really such a hangup to just moving messages and deleting a folder?
(For example, one of the blocks 319743 involved what to do with updating filters when a folder moves. Who cares? Does this matter? Won't filters already fail politely if a target folder is missing? Can't this be ignored?)
(Another block/depends 404955 involved the creation of new right click "move/copy folder" menus and functionalities. Also new ctrl x/c/v functionality. This is more work and not necessary. Drag and drop is already there and works - only the move functionality has to be fixed with this pseudocode instead of doing a copy.)

Etc. etc. Sorry for the longer post but you get my idea. Can't the existing drag/drop of a folder to a new account be corrected (like this pseudocode) to just move each message and then delete the source folder? That would solve ALL of this and kill issues a decade old.

Sorry for the bold text starting my previous post.
Unintentional I messed up the formatting.

Also the pseudocode removed whitespace:

DEFINE FUNCTION to "move AccountA:FolderA to AccountB"

CREATE NEW(empty) FolderB on AccountB (give same name as FolderA)
FOR EACH message X in AccountA:FolderA:
---->MOVE message X to AccountB:FolderB}
DELETE AccountA:FolderA (which is now empty)

"...(Another block/depends 404955 involved the creation of new right click "move/copy folder" menus and functionalities. Also new ctrl x/c/v functionality. This is more work and not necessary. Drag and drop is already there and works - only the move functionality has to be fixed with this pseudocode instead of doing a copy.).."

Actually I would say keyboard functionality is important to those who dont have or can't use a mouse for accessability reasons. What I meant to say was that if the folder drag/drap functionality already exists in Thunderbird, but is just broken in behavior (copies instead of moves). This seems to be a simple code fix (of existing code) as mentioned: just creating a folder, moving each message, then deleting source folder. However the NEW implementation (where it doesn't exist right now) of keyboard copy or move (or right click functionality "move/copy folder") is probably ADDITIONAL code/work with a higher cost to undertake. Furthermore how will 'move folder' via key or right click (as new functionality) work if the existing drag/drop is broken. Logically the easiest and beginning step would seem to be fix of the drag drop to move instead of copy.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.