238846 - Dragging an item from a multi-item attachment list moves wrong item

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Gus Mueller]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316

In cases where there are multiple items in an Attachment list, dragging and
dropping an item out to Explorer always copies the same file, no matter which
item you started with.  Also, there is no way to select all and move them in one
motion.

Reproducible: Always
Steps to Reproduce:
1.Receive email with multiple attachments
2.Drag an item from list out to the desktop.
3.If you're lucky, it will move the one you selected. 
4.So try dragging a different one.  Whoops!

Actual Results:  
Wrong attachment is copied.

Expected Results:  
Copied the correct attachment.

Comment 1

[Mike Cowperthwaite]

I'm seeing this too:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040324

My first guess was that this had something to do with bug 122180, but that 
doesn't seem to be the case.  In the messages I'm testing on, it always seems to 
drag the last item from the list of attachments, regardless of which one is 
selected.

This is a serious malfunction of what will be a touted new feature, so I'm 
requesting 1.7 blocking.

CC'ing mscott, who implemented that new feature.

Comment 2

[Mike Cowperthwaite]

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

Comment 3

[Scott MacGregor]

taking

Comment 4

[Scott MacGregor]

Attachment: the fix

the fix is to give the moz-url flavor precedence. I can still drag to the
desktop and it ends up being a file without a problem.

There is still one issue I need to fix here. It looks like the drag and drop
toolkit code is calling the file flavor object which causes us to take the drag
data and save it to a temp file even though the drop ends up ignoring the
moz-promise-file flavor. Hence, I can see a little progress window dialog popup
when I drag an attachment to the compose window.

I think the drag and drop toolkit code needs modified to only call the
moz-promise-file flavor provider if and only if the drop target cares about
that flavor type.

Comment 5

[Scott MacGregor]

Comment on attachment 145322 [details] [diff] [review]
the fix

i accidentally posted this patch to the wrong bug

Comment 6

[Scott MacGregor]

Attachment: fix for thunderbird and seamonkey

it is all in the formatting.....

when dragging moz-url's, the old behavior was appending content type and file
name information to the attachment url. 

The new code that was added for dragging attachments to the desktop was picking
up this same extra information at the end of the url string. But when we later
take that url and iterate over our attachment elements in msgHdrViewOverlay
(currentAttachmentData) we couldn't find a match because the url had this extra
stuff appended to it.

The fix is to leave the moz-url flavor alone with its extra information. But
the new file drop code should use a plain vanilla url that doesn't have that
extra stuff appended to it. Now we find the attachment url in our list of
current attachment data and we drop the right attachment to the desktop.

Comment 7

[Scott MacGregor]

Comment on attachment 145563 [details] [diff] [review]
fix for thunderbird and seamonkey

See 
comment #6 for a description of the patch.

Comment 8

[Scott MacGregor]

Comment on attachment 145563 [details] [diff] [review]
fix for thunderbird and seamonkey

asking for 1.7 approval. low risk fix for a new mail feature in 1.7

Comment 9

[chris hofmann]

Comment on attachment 145563 [details] [diff] [review]
fix for thunderbird and seamonkey

a=chofmann for 1.7

Comment 10

[Scott MacGregor]

fixed for seamonkey and mozilla