Closed Bug 238846 Opened 20 years ago Closed 20 years ago

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


(SeaMonkey :: MailNews: Message Display, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: gus, Assigned: mscott)




(1 file, 1 obsolete file)

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

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.
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 

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.
Ever confirmed: true
Flags: blocking1.7?
*** Bug 238921 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla1.7final
Assignee: sspitzer → mscott
Attached patch the fix (obsolete) — Splinter Review
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 on attachment 145322 [details] [diff] [review]
the fix

i accidentally posted this patch to the wrong bug
Attachment #145322 - Attachment is obsolete: true
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 on attachment 145563 [details] [diff] [review]
fix for thunderbird and seamonkey

comment #6 for a description of the patch.
Attachment #145563 - Flags: superreview?(bienvenu)
Attachment #145563 - Flags: superreview?(bienvenu) → superreview+
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
Attachment #145563 - Flags: approval1.7?
Comment on attachment 145563 [details] [diff] [review]
fix for thunderbird and seamonkey

a=chofmann for 1.7
Attachment #145563 - Flags: approval1.7? → approval1.7+
fixed for seamonkey and mozilla
Closed: 20 years ago
Resolution: --- → FIXED
Flags: blocking1.7?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.