634720 - drag and drop to desktop does not work with multiple messages

Status: REOPENED

(Thunderbird :: OS Integration, defect)

Description

[John Antell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110114 Thunderbird/3.3a2

It is possible to select a single message and drag it to the desktop

You can select multiple messages but when you try to drag them to the desktop, it does not work. The No Entry symbol appears.

Reproducible: Always

Steps to Reproduce:
1. select a message
2. Hold CTRL and select another message (two messages should now be highlighted
3. Click and hold mouse over selected messages and drag to desktop
Actual Results:  
No entry sign. Messages not dropped to desktop

Expected Results:  
Copy of messages should appear on desktop

Comment 1

[Jim Porter (:squib)]

This is on my radar to do (one day), but it's a pain in the butt, since I'd have to go hacking around in a lot of OS-specific code.

Comment 2

[John Antell]

From the description of bug 270292, I am not sure it is a duplicate. Bug 270292 is described as being a problem with dragging multiple attachments, whereas this is a problem with dragging multiple messages. (Maybe they have a common cause but certainly the description of the symptoms seems different to me.)

If it is not easy to correct the problem with dragging multiple messages, would it be possible to change the file names of the messages to avoid duplication? The main problem with dragging messages one by one is not so much that you have to do a lot of drags but rather that most messages are likely to have the same subject. Because the filename is the same as the subject, when you drag the second and subsequent messages you get a error message asking if you want to overwrite the first because they have the same name. Would it be possible to change Thunderbird so that the filename of each message is unique, say YYYY MM DD hh.mm.ss [SUBJECT] rather than just [SUBJECT] so as to avoid this problem?

Comment 3

[Phil Lacy]

Bug 227305 has the patch for d&d of messages. It may be a good start point to see where the front end takes place. It's different then 270292 so I'm going to reopen here. Change back to dupe if incorrect.

Comment 4

[Vincent (caméléon)]

(In reply to John Antell from comment #2)
> Would it be possible to change Thunderbird so that the filename of
> each message is unique, say YYYY MM DD hh.mm.ss [SUBJECT] rather than just
> [SUBJECT] so as to avoid this problem?

This is the case on trunk (and maybe also in thunderbird 6), but only if you use "File | Save as" with multiple messages selection. So the code is there, it just need to be implemented into the drag and drop code.

Comment 6

[u406841]

Please fix this bug! It will remove needle from my feet! I'ts one of the reason why Thunderbird is not deployed entirelly in my enterprise!

Comment 7

[u406841]

 "but only if you use "File | Save as" with multiple messages selection. So the code is there, it just need to be implemented into the drag and drop code."

I want to inform you this function have some problem too. In some case, with a bunch (2 or more) email some email are missing when saving using this method. I can provide the email which generate the problem if necessary. If we save one problematic email at a time it work but not when we save multiple message.

Comment 8

[Steve]

(In reply to Jim Porter (:squib) from comment #1)
> This is on my radar to do (one day), but it's a pain in the butt, since I'd
> have to go hacking around in a lot of OS-specific code.

It is not so complicated, but i'm not a C programmer and can't do it myself... :( Basically the nsDataObject should do this work. But in response to a CFSTR_FILEDESCRIPTOR it should return a FILEGROUPDESCRIPTOR structure, which basically consits of 4 bytes integer (count of the FILEDESCRIPTOR structures) followed by one FILEDESCRIPTOR for each selected message. As far as I can estimate, the rest of code looks good. Perhaps the FILEDESCRIPTOR should contain some more data, like creation date, modified date and the size of the message. Don't forget to set the specific flags in the dwFlags member. 
Than deliver the content of the requested message as stream in response to a CFSTR_FILECONTENT, just as is now implemented with a bit difference: the lindex member of FORMATETC MUST be the zero based index of the file requested. Therefore I would change the behavior, if a wrong index is given, return DV_E_LINDEX. At the moment -1 is interpreted as 0.
I don't know what nsDataObjectCollection should do, but it seems to deliver the requested data from the first contained nsDataObject that can deliver the requested data. What is this collection / behavior good for?
The file names in the structures don't even need to be unique, the drop target can make whatever it wants with them.

Comment 9

[Fran]

Thanks for the Save AS note.  It does work, but...
I have one more to add to this problem.  On windows 7 the new TB 17, once I get all emails to a folder, either by the wonderful ImportExportTools add on, or by transfering it from my XP folder on my virtual to my Win 7 folder, and now, even with the SAVE AS method, it won't let me delete any of the messages in that folder.  I can easily drag and drop all those messages into TB, but getting them to delete does not work.  Now, on XP I can delete any single message from the folder, and also on my Win 8, so I have tested this on different formats.
The reason it's annoying, is that when I finally read that message and no longer want it, I can't delete it.  I can delete the whole folder, but not the message in the folder.  I can even delete the messages one by one from Win 8 or XP through the network connection, but it does not work on Win 7.
I was hoping to get rid of my virtual which I only use for Outlook Express and I am not upgrading my PC to Win 8 because I hate Win 8, which in my opinion is as bad as Vista was.

Comment 10

[Anje]

Using vista and version 24.0.1
Still unable to drag and drop more than one email into a folder or onto desktop.
According to :https://getsatisfaction.com/mozilla_messaging/topics/drag_drop_mails_in_eml_format_from_thunderbird_to_a_random_folder_on_my_pc

this was under consideration 3 years ago.

Can anyone provide more updates on when this will be provided?

Comment 11

[Thomas D. (:thomas8)]

(In reply to Anje from comment #10)
> Using vista and version 24.0.1
> Still unable to drag and drop more than one email into a folder or onto
> desktop.
> According to
> :https://getsatisfaction.com/mozilla_messaging/topics/
> drag_drop_mails_in_eml_format_from_thunderbird_to_a_random_folder_on_my_pc
> 
> this was under consideration 3 years ago.
> 
> Can anyone provide more updates on when this will be provided?

Hi Anje, always nice to see you around in TB getsatisfaction support and bugs. Thanks for standing by Thunderbird... You'll be aware that TB is now maintained by volunteers like us :)

I can't tell when this will be provided (unless we manage to convince :squib to do it, but see his comment 1). However, in the meantime, here's a convenient way of saving multiple messages as individual .eml files to your file system:
- select multiple msgs (e.g. with ctrl+click)
- Ctrl+S, choose folder -> DONE! :)

Does that help for your scenario?

Comment 12

[Thomas D. (:thomas8)]

(In reply to Steve from comment #8)

Jim, could you comment on Steve's comment and answer his question about nsDataObjectCollection?
I vagely recall the drag & drop of multiple files was discussed somewhere else, and, in line with Steve's comment, the answer was that we already have internal methods (nsDataObjectCollection?) which will pass multiple files to the file system one by one. If that's true, than perhaps it might be easier to fix this than you expected in your comment 1?

> (In reply to Jim Porter (:squib) from comment #1)
> > This is on my radar to do (one day), but it's a pain in the butt, since I'd
> > have to go hacking around in a lot of OS-specific code.
> 
> It is not so complicated, but i'm not a C programmer and can't do it
> myself... :( Basically the nsDataObject should do this work. But in response
> to a CFSTR_FILEDESCRIPTOR it should return a FILEGROUPDESCRIPTOR structure,
> which basically consits of 4 bytes integer (count of the FILEDESCRIPTOR
> structures) followed by one FILEDESCRIPTOR for each selected message. As far
> as I can estimate, the rest of code looks good. Perhaps the FILEDESCRIPTOR
> should contain some more data, like creation date, modified date and the
> size of the message. Don't forget to set the specific flags in the dwFlags
> member. 
> Than deliver the content of the requested message as stream in response to a
> CFSTR_FILECONTENT, just as is now implemented with a bit difference: the
> lindex member of FORMATETC MUST be the zero based index of the file
> requested. Therefore I would change the behavior, if a wrong index is given,
> return DV_E_LINDEX. At the moment -1 is interpreted as 0.
> I don't know what nsDataObjectCollection should do, but it seems to deliver
> the requested data from the first contained nsDataObject that can deliver
> the requested data. What is this collection / behavior good for?
> The file names in the structures don't even need to be unique, the drop
> target can make whatever it wants with them.

Comment 13

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #12)
> (In reply to Steve from comment #8)
> 
> Jim, could you comment on Steve's comment and answer his question about
> nsDataObjectCollection?
> I vagely recall the drag & drop of multiple files was discussed somewhere
> else, and, in line with Steve's comment, the answer was that we already have
> internal methods (nsDataObjectCollection?) which will pass multiple files to
> the file system one by one. If that's true, than perhaps it might be easier
> to fix this than you expected in your comment 1?

Indeed, there's a comment on bug 270292 from Kyle who was involved with coding nsDataObj, confirming that we can use nsDataObjCollection class to wrap multiple nsDataObjects and handle them serially:

(In reply to Kyle Huey [:khuey] ([e-mail]) from bug 270292, comment #49)
 
> It's been a while, but if I remember correctly, each nsDataObj corresponds
> to a single "thing" that is being dragged and dropped.  If multiple things
> are being dragged and dropped there is an nsDataObjCollection class that
> wraps a series of nsDataObj, one for each separate item.

I'm not into this code, but if we already succeed with dropping a single item, and we have an internal method to handle a series of nsDataObj and dish them out one by one, then it might be possible to combine the two without major OS-specific hacking?

Similarly, given that we succeed for saving multiple .eml files to an OS folder using "Save as...", can we take ideas or code from there?

Comment 14

[Jim Porter (:squib)]

Sorry, I've pretty much completely forgotten about everything in this bug, so I'm not going to be much help here.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to Anje from comment #10)
> Using vista and version 24.0.1
> Still unable to drag and drop more than one email into a folder or onto desktop.
>(snip)
> this was under consideration 3 years ago.

What kind of phenomenon do you call by "unable to drag and drop"?
Drag is possible but Drop is impossible? Only one mail is saved by Drag&Drop?
What do you call by "Still"?
Absolutely same phenomenon/symptom in any Tb release? Is there any difference between Tb 17 and Tb 24?

FYI.
IIUC, patch of bug 812923 stopped generating multiple file names upon Drag of multiple mails, in ordre to avoid performance problem in Dragstart. It was done because "Dragging multiple messages to desktop" does not currently work then no need of "multiple file names". The patch was landed on Tb 24. Following is comment in the patch source.
+  // Dragging multiple messages to desktop does not currently work.
+  // When core fixes for multiple-drop-on-desktop support
+  // (e.g. bug 513464, bug 270292) are landed, generating of
+  // "application/x-moz-file-promise" values for i > 0 can be enabled.
+  // But first ensure suggestUniqueFileName is efficient enough on 10000+ dragged
+  // messages.

Comment 16

[Steve]

(In reply to WADA from comment #15)
> 
> What kind of phenomenon do you call by "unable to drag and drop"?
> Drag is possible but Drop is impossible? Only one mail is saved by Drag&Drop?
> What do you call by "Still"?

With TB 24.1.0 yo can start a Drag operation, but you can't drop on Explorer, if more than one message is selected. Years ago the behavior was, that you could drop more Messages but only one got saved.

If it would help, I could write a sample program in C#, to demonstrate a drag&drop with virtual files using CFSTR_FILEDESCRIPTOR & co. I can't do it with c++. Or suggest a good IDE for Linux, than i could try to patch the sourcefiles of TB :)

Greets

Comment 17

[Thomas D. (:thomas8)]

Pending patch in bug 270292, attachment 8414758 [details] [diff] [review], will also fix this bug. If we can make that land before it bitrots...

Comment 18

[Martin Stránský [:stransky] (ni? me)]

On Linux it's fixed by Bug 1800972. The remaining one is wrong drag visualization - Bug 1802096.