253711 - Attachment drag-and-drop fails if dropped too soon

Status: RESOLVED WORKSFORME

(MailNews Core :: Attachments, defect)

Description

[Greg Colyer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707

When an attachment is dragged from an IMAP message and dropped in a Windows XP
folder, the following error sometimes appears: "Cannot move <attachment name>.
It is being used by another person or program. Close any program that might be
using the file and try again." The Download Manager then opens and shows the
file being downloaded to C:\Documents and Settings\<user>\Local Settings instead
of the target folder. On completion of the download, the file doesn't move to
the target folder. On cancellation part-way through the download, the partial
file is left in the Local Settings folder and is not immediately deleted.

I have only been able to reproduce the problem with large attachments,
suggesting a race-condition. Is Mozilla trying to move the file before it has
yet created it? I also wonder whether this bug has anything to do with the
recent change to the way in which downloads are migrated to their destination
directorym, per bug 55690.

Note that the dragging cursor does not have a "+" icon (meaning copy), but an
"empty" icon (meaning move, as the error says), even though a dragged attachment
does not disappear from the message. This may be considered a separate bug.

Reproducible: Sometimes
Steps to Reproduce:
1. Open IMAP message folder
2. Find message with large attachment
3 [review]. Drag attachment and drop into Windows XP folder

Actual Results:  
Error message appeared and attachment was misplaced into Local Settings folder.

Expected Results:  
Attachment should have been placed in target folder.

None of the above is necessarily specific to IMAP or Windows XP, but I haven't
tested other possibilities.

Comment 1

[Mike Cowperthwaite]

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

Comment 2

[Mike Cowperthwaite]

This is easy to reproduce with IMAP, but doesn't occur for POP.
Reproduced with TB 0.9, Win2K.

As noted at the dupe, a workaround is to use Ctrl+drag, which "makes a copy"
of the attachment.  (Technically, the copy cursor should always be used, but 
that's another bug.)

Comment 3

[Mike Cowperthwaite]

See also bug 252479.

Comment 4

[Brett Leber]

If, when dragging the attachment from TB to a folder, you wait for the download 
window to open and close and THEN let go of the mouse, the file is moved fine.

Comment 5

[Mike Cowperthwaite]

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

Comment 6

[Mike Cowperthwaite]

(In reply to comment #2)
> This is easy to reproduce with IMAP, but doesn't occur for POP.

This may be a timing issue -- a very similar problem is reported with POP at 
bug 285296.

Comment 7

[Jeongkyu Kim]

(In reply to comment #6)
> This may be a timing issue -- a very similar problem is reported with POP at 
> bug 285296.

Hello,

I came from bug 285296. And I still can reproduce the problem with POP3 (and 
with IMAP also). As far as I observe, this bug is caused by very simple 
reason. The 'drag and drop' operation is handled in two steps - copying 
attached file to default folder followed by moving it to target folder. 
Unfortunately, thunderbird doesn't check if copy operation is completed when 
mouse button is released (when it starts to move the file). So, the file can't 
be moved when copy operation hasn't been completed. And this situation could 
be interpreted as 'the attachement was misplaced'.

Workaround? You may give enough time for thunderbird to complete copy 
operation. Don't release the mouse button too quick. A possible solution is to 
let thunderbird check and wait for file copy being completed. :-) 

QA,

I'd like to suggest to mark bug 285296 as dupe of this bug and to change the 
summary of this issue to more general one.

Comment 8

[Mike Cowperthwaite]

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

Comment 9

[Aaron Lawrence]

Updated summary to reflect what's going on better.
I too have this problem with POP3 - more often than not, as people often send us 1MB+ files. 
Unfortunately the workaround is not very discoverable, so it just looks like drag-n-drop is completely dead in these cases. After maybe 20 times I worked it out, but other users would not be so tolerant.

I would also argue that showing the download window in this case is inappropriate and unhelpful - dialogs shouldn't appear during just the drag portion of the operation. 
In fact, why DOES mozilla copy the file to a temporary before the drop occurs? Perhaps it is in order to set the drag object type? 

Comment 10

[Aaron Lawrence]

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

Comment 11

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

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 13

[Oliver Fischer]

It is planed to solve this bug? It is a little bit disturbing.

Comment 14

[Aaron Lawrence]

This is the kind of fairly basic bug that I would hope the paid Mozilla staff would actually work on, but it seems being employed by Mozilla is actually a license to work on all the fun stuff.

Comment 15

[Patrick]

Oh come on! I didn't even want to believe my colleague who reported this issue to me. Can you imagine how hard he laughed when I told him that he should drag & drop  slower, in order to prevent data corruption?
There are people who actually *use* the features that Thunderbird claims to offer (IMAP, drag & drop), how can they be left in such a bad shape for *years*?

Comment 16

[Magnus Melin [:mkmelin]]

Oliver, Arron, Patrick: can you still reproduce with a recent tb3 dev build?

http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/

Comment 17

[Patrick]

(In reply to comment #16)
> Oliver, Arron, Patrick: can you still reproduce with a recent tb3 dev build?

I just did a quick check with rv:1.9.1b3pre Gecko/20090121 Shredder/3.0b2pre and couldn't reproduce the bug. I also saw that a "Moving..." window came up after dragging and dropping the attachment into an Explorer window for a few seconds, which didn't happen in Thunderbird 2.

Good work! :)

Comment 18

[David :Bienvenu]

ok, thx, marking wfm - please re-open if you do see the problem again.