Closed Bug 238846 Opened 20 years ago Closed 20 years ago
Dragging an item from a multi-item attachment list moves wrong item
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 238921 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.7final
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 See 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
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.