84905 - Moving message across accounts actually does copy the message

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[Robert Kaiser]

If I'm trying to move a message across accounts (e.g. from my POP3 Inbox to a
folder in "Local Folders"), it actually gets copied.
I'm trying to drag&drop, to use the "File" button, and to use "Message" > "Move
Message" menu item, but Mail is always copying the messages. The interesting
thing is that it seems to work correctly within the same account.
You can argue about dnd, but "File" and "Move Message" should always move, not
copy, right?

This is happening since a few days, if I remember correctly. I'm now on
2001-06-07-09 Linux nightly trunk build.

Comment 1

[Håkan Waara]

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

Comment 2

[Håkan Waara]

I'm wondering if this is a feature or bug, anyhow it's important and should
probably be looked at before the next milestone.   cc putterman and nominate.

Comment 3

[esther]

Using build 2001-06-07 on win, linux and mac I can DragNDrop, Button File|move, 
Menu Message|Move Message and context menu Move to>.  All of these moved the 
message from my POP inbox to my Local Folders folder  "bugxzy".  If there is 
something else to your steps to reproduce, please let me know.  I can't 
reproduce this on the branch build.

Comment 4

[scottputterman]

cc'ing naving.  I just saw on another bug that cross server moves do a copy. 
Navin does this only apply from IMAP to Local or does this apply to local to
local (or POP) as well?

Comment 5

[Navin Gupta]

marking this bug as invalid. Anything not within the same account should be a 
copy. pop acct to local acct is different server; so should be a copy. 

Comment 6

[scottputterman]

This doesn't seem correct to me.  I'd think I could move a message from one
server to my Local Folders.  Is there a bug associated with this change?  I'd be
interested in reading the comments.

Comment 7

[Ken Harris]

I just downloaded latest-trunk from ftp.mozilla.org (2001061108)
and can confirm all 4 methods still copy, not move.

I think this is still valid -- if I right-click a message in my
normal e-mail account (in my case, POP3), Move To -> Local Folders
-> Trash, why would I ever want that to make a copy in the local
Trash, and keep the original in my Inbox?

If "Move To" and "Copy To" are going to do the same thing, why do
they both exist?

Comment 8

[Navin Gupta]

I changed it in this bug 82764. I can change it back but I have seen 4x also 
does a copy. May be we should allow move to local folders.

The menu can be changed once we know what we should allow. 

Comment 9

[Navin Gupta]

reassigning to self. 

Comment 10

[jglick]

This is what I think is appropriate:

Drag and Dropping:
- Within the same account, from one account folder to another account folder 
should perform a Move.
- Within the same account (POP or IMAP), from an account folder to a Local 
Folder should perform a Copy.  (4.x for IMAP currently works this way, which I 
think is appropriate. I think we should be consistent with POP also in this 
multiple account environment)
- Two different accounts, From one account folder to another, should be a Copy.

Using the "File" button on the toolbar should work the same as drag and drop.

Using the "Message --> Move" menu item should always perform a Move (regardless 
of within the same account or from one account to another). 

Using the "Message --> Copy" menu item should always perform a Copy (regardless 
of within the same account or from one account to another).

Comment 11

[jglick]

4.x:  When holding down the Shift key and dragging and dropping, you Always get 
a Move action.  It would be nice to keep this behavior.

Also, we need to be sure to display the correct Move or Copy cursor when 
dragging and dropping.

Comment 12

[Navin Gupta]

jglick, thanks for the clarification. I made Drag and Drop, by default (with no
shift key pressed) across servers/accounts to do a copy. However, I will have
to change how File Button and Message | Move/Copy works. 

Comment 13

[Ken Harris]

Maybe this is a separate issue (and maybe it's been discussed before),
but here's what's on my mind...

I have a POP3 account, and it has a Trash.  Local Folders also has a
Trash.  With the system jglick proposes (which seems mostly reasonable),
dragging a message to the trash might be a copy, and might be a move,
depending on which trash it is.

I can't get it to work right now, but my recollection is that on 4.x
there was only one Trash, so this wasn't an issue.  (Why do I have 2
Trashes now?  I'm not entirely sure.)

"Drag to Trash" in my mind is synonymous with "Delete the sucker".
I never think "I'll just make a copy of this in the Trash folder on
my other account".

(Or maybe I'm the only one this is bugging?  Let me know if I'm out
of line here.)

Comment 14

[scottputterman]

I'm just going to summarize what I think needs to be done:

1.  Drag and drop across accounts can continue to do a copy but we need to
change the cursor to show a copy cursor and we need to make shift change it to a
move.

2.  File remains as is and does the same as drag and drop

3.  Move returns to doing a move.

Comment 15

[jglick]

Ken, I think thats a good question.  4.x does have two Trash cans, for IMAP 
anyway.  One with the account folders and one with the Local Folders.  Dragging 
from an account folder to the Local Trash in 4.x does a Copy.  I agree, this 
seems silly. Is it possible to detect if the user is dragging to a Trash folder 
and do the right thing (Make it a Move action)?

Comment 16

[Navin Gupta]

In 4.7 File button does move messages across server/account so the behavior 
should be like Message | Move, not like Drag and Drop

Comment 17

[Navin Gupta]

Attachment: patch to make the move and file return to original behavior

Comment 18

[Navin Gupta]

logged bug 85515 about the shiftKey and icon issue associated with drag and 
drop, since it is a separate issue. 

Comment 19

[Ken Harris]

That sounds good to me: drag-to-Trash = move is a special case. (If I was
dragging, say, a template across accounts, I'd probably want it to be copied,
so that behavior stands.)

I'd think that if Mozilla knows to give it a trashcan icon, it knows it's
the Trash, but I won't claim to be an expert on mailnews internals.

Comment 20

[Navin Gupta]

why can't you drag it to trash folder within the same account if you want to 
delete it. Moreover, this is a separate issue; please log a separate bug.  

Comment 21

[jglick]

>In 4.7 File button does move messages across server/account so the behavior 
>should be like Message | Move, not like Drag and Drop

I don't necessarily agree with that logic. Why is the "File" button called 
"File" instead of "Move"?  I had thought it was called File because it wasn't 
clearly a copy or a move but depended on where the message was being Filed to, 
like DnD. (I see now that 4.x does work as naving describes.)  Putterman, if 
this is the case, is there a reason "File" was called "File" instead of "Move"?

Comment 22

[Ken Harris]

Per Navin's suggestion, filed bug 85532: Dragging a message to (any)
Trash should always move (not copy).

Comment 23

[scottputterman]

File does a copy when filing a news message into a mail folder.

Comment 24

[Navin Gupta]

I agree with you but the basic operation is move; we check in js code if it 
is news and issue a copy instead of move. I think reverting to original changes
would be fine. 

Comment 25

[scottputterman]

Sorry, I was answering Jennifer's question about why calling the button Move
wouldn't be an accurate description.

Comment 26

[David :Bienvenu]

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

Comment 27

[Navin Gupta]

request for code review from david and seth. 

Comment 28

[racham]

r=bhuvan

Comment 29

[Jesse Ruderman]

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

Comment 30

[Jesse Ruderman]

IMO this should be fixed by making drag/"move" always move, and ctrl+drag/"copy"
always copy, like it works in other e-mail programs.  I rarely copy messages,
but I move them very often, and I don't see why an e-mail program would assume I
want to copy simply because I'm dragging to a different server.  (Btw, Mozilla
has only assumed drag-across-servers means move for a week now, and it's already
been reported a bug four times.)

Comment 31

[David :Bienvenu]

sr=bienvenu

Comment 32

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 33

[Navin Gupta]

fix checked in.

Comment 34

[Håkan Waara]

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

Comment 35

[Aleksey Nogin]

Just tried it on 2001061411 Linux RH7 RPM build, had the same problem - when
doing D&D from POP Inbox to a Local folder, I get a copy, not a move.

Comment 36

[Navin Gupta]

Drag and drop will do a copy from pop to local. See jglick's comments. 

Comment 37

[Aleksey Nogin]

This does not make any sense for POP. Why would you want to D&D from Pop to
Local to do a copy? You receive a new message, you read it and you D&D it to an
appropriate local folder for archiving. Why copy??? Also, this is
counterintuitive and confusing. 

Comment 38

[scottputterman]

There needs to be further discussion on this. Moving to 0.9.3

Comment 39

[Jesse Ruderman]

Why should dragging act differently depending on whether you have a POP or IMAP
account?

Comment 40

[Aleksey Nogin]

Well, with POP you normally file your messages locally, but with IMAP you are
likely to file them on the same server as Inbox. Because of that this bug is
much more annoying for POP then for IMAP. 

However, IMHO the best solution would be to make D&D (without modifier keys)
always move, and have a modifier key variant that will always copy. IMHO any
"sometimes copy, sometimes move" solution would be confusing, but the ones where
POP Inbox -> local is a copy and local -> local is a move are especially confusing.

Comment 41

[jglick]

>Well, with POP you normally file your messages locally, but with IMAP you are
>likely to file them on the same server as Inbox. Because of that this bug is
>much more annoying for POP then for IMAP. 

Say a user has two accounts, one IMAP and one POP. For users who don't know 
there is a difference between POP and IMAP (they just enter the server info as 
given to them when they signed up for the account) it might be confusing that 
DnD from one account to a Local Folder does a Copy and from another account does 
a Move.

>However, IMHO the best solution would be to make D&D (without modifier keys)
>always move, and have a modifier key variant that will always copy. IMHO any
>"sometimes copy, sometimes move" solution would be confusing, but the ones 
>where POP Inbox -> local is a copy and local -> local is a move are especially 
>confusing.

Yeah, I'm starting to think you might be right on this one. DnD is always a Move 
and Modifier + DnD is always a copy. My only worry is that is it bad that we 
wouldn't follow the Windows Explorer convention of Server to Local or Server to 
Server is always a Copy and Local to Local is always a Move?

Comment 42

[jglick]

p.s. I'd really like to see "File" removed from the Toolbar. Isn't 2 ways, DnD 
and Menus (Message--> Move/Copy) to do the same thing enough?

Comment 43

[Aleksey Nogin]

> My only worry is that is it bad that we 
> wouldn't follow the Windows Explorer convention of Server to Local or Server to 
> Server is always a Copy and Local to Local is always a Move?
1. We can try addressing that by using a suggestive icon, so that it's obvious
when we are moving and when we are copying (the current one, at least on Linux,
is terrible) - do we have a bug filed for that one?
2. If WE is doing something funny and confusing does not mean Mozilla have to do
the same ;-)
3. At least it's not going to be confusing on other platforms

Comment 44

[timeless]

jglick: the toolbars will be customizable eventually (i'm hoping before 1.0, 
but i'm not sure, ask ben), as such i am opposed to removing support for 
functionality.
Feel free to file a bug suggesting that we default to disabling that item by 
default after we implement customizable toolbars.
Please remember that someone might decide to hide their menubar and use only 
buttons.
mpt is trying to convince everyone that cascading context menus are bad, so if 
both you and him prevail we'll have only one way to do this (*mpt actually 
suggested a replacement based on nc4mac-messenger's implementation, which 
resembles icq's context meuns, but his general view is no cascading).

Comment 45

[scottputterman]

So, I've had a few people tell me that they prefer copy across account on Drag
and Drop.  And Windows Explorer does do it this way. But, I tried OE and it does
a move, and I've gotten really used to a move over the last few years that going
to a copy feels strange to me.  I'm in favor of making Drag and Drop always do a
move and having shift+Drag do a copy (unless of course you are in News where it
does a copy).

That's my opinion.  Do others have any opinion on this that haven't contributed
to the discussion?

Comment 46

[Håkan Waara]

From the book "User Interface Design for Programmers"
(http://joel.editthispage.com/stories/storyReader$51):

``To make people happy, you have to let them feel like they are in control of
their environment. To do this, you need to correctly interpret their actions.
The interface needs to behave in the way they are expecting it to behave.''

If a user is dragging a message out of an account onto a folder in another, it
mostly like wants it to _move_ there. That is the functionality drag&drop has
provided for years on MacOS and Windows. I totally agree with putterman that
dragging a message across accounts should move it in all cases where it's possible.

Comment 47

[timeless]

hwaara: pasting quotes that are inaccurate is not recommended.

the windows behavior as people have tried to explain is to copy when dragging 
from drive to drive.  This is indeed the macos implementation too -- checked w/ 
vnc this is indeed the behavior, it even gives me a very clear + sign.

macos does this for the noble reason of not wanting you to lose your data in 
the event the copy fails.  Windows usually does things like this because it's 
imitating macos (while this is not considered a noble reason many ui people 
consider it a good enough reason to jump off a cliff ~macos does it that way~).

There are a few minor caveats to the windows implementation but they do not 
apply to data which is the subject for this dicussion.

Comment 48

[Aleksey Nogin]

Attachment: Always do move (not a copy) on message D&D

Comment 49

[Aleksey Nogin]

So far it seems that we have a consensus that D&D (wthout a modifier key) should
always do a move and not a copy. Should this bug be retargeted back at 0.9.2?

I attached a patch that rolls back the change in messengerdnd.js that started
making a copy on D&D between accounts.

Comment 50

[Christopher Blizzard (:blizzard)]

If you're doing a move you shouldn't delete the source until it's known for sure
that the write to the new location worked.  That argument is a complete red herring.

I think that consistency is very importand what we do now which is move
sometimes and copy other times is very inconsistent.  I think that we should
move instead of copy by default for this reason.

Comment 51

[Navin Gupta]

We don't do a delete until the copy has succeeded. Does everyone agree on
changing default drag and drop behavior across servers to *MOVE*

Comment 52

[(not reading, please use [e-mail] instead)]

first, let's find out what 4.x does.

"local server" would be servers like pop3, "Local Folders", movemail, where the
folder is on disk.

within same account, except for news (move)
"local server" -> "local server" (move)
imap -> imap (copy)
imap -> "local server" (not sure?)
"local server" -> imap (not sure?)
news server -> * (copy, you can't move a news message)

I believe the reason we do copy instead of move in some cases is for dataloss.

here's the dataloss:  you messages from an IMAP server to somewhere, and it
fails but we don't handle the error properly.  the last thing you want to do is
delete the original messages, thinking you've moved them.

for "local servers", since everything is on disk, this silent failure is not as
likely so we just do the move.

the typical user is a pop user, and all there mail is local on disk, and so in
this case, d&d of messages should be a move.

bienvenu would know more.

Comment 53

[Navin Gupta]

> here's the dataloss:  you messages from an IMAP server to somewhere, and it
> fails but we don't handle the error properly.  the last thing you want to do 
> is delete the original messages, thinking you've moved them.

This is nothing but a bug, so what we want to do should not be affected by it.

Comment 54

[Jesse Ruderman]

If copying a message across servers doesn't return an error message when it
fails, moving that message will lead to dataloss whether we fix this bug or not.
 If we fix this bug, dragging a message across servers will lead to immediate
dataloss; if we don't, it will lead to dataloss as soon as the user realizes
Mozilla copied the message he was trying to move it and manually deletes the
original copy.

Comment 55

[scottputterman]

I talked to David before he left about this and he liked it as a copy (hence my
reference to people who liked the copy).  For me, I find that I expect drag and
drop to do a move. Especially when doing anything to local.  As has been
mentioned, I would drag and drop to local in order to store rather than
duplicate(in fact I only drag and drop to any place to store) so I feel making
it a copy adds to steps to anything I would do.

Comment 56

[Aleksey Nogin]

> I talked to David before he left about this and he liked it as a copy
>
People who like copy can always do Ctrl-D&D.

> I believe the reason we do copy instead of move in some cases is for dataloss.
>
Wl,, We still have a Move and Copy in a menu, so why should we be afraid of
dataloss in D&D, but not in Move through menu?

But if people are really afraid of dataloss, we can implement a safety mechanism
(for both D&D and menu-driven moves). Basically, we have two classes of scenarious:
1) D&D to local. According to other comments this is not much dataloss danger.
2) D&D to Imap. If people are really afraid about dataloss, how about the
following doing a move through the following sequence of steps:
 - Do a copy
 - retrieve the copied message back from the server, make sure copied OK
 - delete original.

This way we can sure that neither Mozilla nor Imap server bugs (nor combination)
could cause a dataloss.

Comment 57

[Aleksey Nogin]

It seems that the fix for bug 85921 regressed the situation with D&D so that
even with my patch, I still get a copy, not a move!

Comment 58

[Aleksey Nogin]

Sorry, strike that, it was my mistake, bug 85921 didn't regress anything (as far
as I can tell). The patch in attachment 38597 [details] [diff] [review] still does the right thing
(provided you agree that the right thing is to always move on D&D :-) ).

Sorry about the spam.

Comment 59

[scottputterman]

moving back to 0.9.2

Comment 60

[Peter O'Shea]

I strongly vote with the opinion that the default D+D behavior should be move,
not copy.  95% of the time, when you are performing an action on a message, it
is to move it, not to copy it.  I'm willing to hold down a modifier key for the
very occasional times I'm copying, but requiring the modifier key for the 95% of
the time that I'm moving - that's wrong.

Comment 61

[Navin Gupta]

Attachment: pact to make D&D across servers to do a MOVE

Comment 62

[Scott MacGregor]

sr=mscott

Comment 63

[racham]

r=bhuvan

Comment 64

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

a=dbaron for trunk checkin (on behalf of drivers)

Comment 65

[Navin Gupta]

fix checked in.

Comment 66

[Peter Lairo]

DND still doesn't do a *move* in build 2001-06-20.

Is this not covered by this bug. I filed bug 86849 to explicitly fix this.

Comment 67

[Peter Lairo]

BTW, even though i downloaded and installed the latest nightly called:

- mozilla-win32-installer-sea-talkback.exe 20-Jun-2001 21:55   8.4M 

under help - about mozilla, it says gecko 20010618 - why?

Comment 68

[Robert Kaiser]

PLairo: In my gcc952 nightly (ID 2001062009), DnD is moving.

Comment 69

[Peter Lairo]

WFM now too. Aparently, there is something wrong in the FTP/latest nightlies
directory (older build file there, but labelled current)

Comment 70

[Peter Lairo]

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

Comment 71

[Karen Huang]

Ccing myself.

Comment 72

[Sheela Ravindran]

Using branch buildid:  2001062806 win98, 2001062706 mac, linux. 
This was fixed on the trunk build before the 0.9.2. So I will mark this as
verified.  
I tested moving a single message by drag&drop, file button, menu item-message|move
and the scenarios were:
imap to pop, pop to imap, imap account1 to imap account2, pop account1 to pop
account2, imap - local, local - imap, within pop account, within imap account
all resulted in move by drag and drop, file button, menu item. 

Comment 73

[Ken Harris]

With 2001070406, Linux: I just tried to drag a message from my POP3 Inbox
to a local folder, and it didn't do anything.  Right-click > Move To
worked fine.  Can anybody confirm?

Comment 74

[Jesse Ruderman]

One case of this bug hasn't been fixed, or has regressed since this bug was 
fixed.  Filed bug 124582, dragging *folder* across accounts copies instead of 
moving.