Closed Bug 227305 Opened 21 years ago Closed 15 years ago

Support drag-drop single message to desktop / file-system window (e.g. Explorer)

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.0rc1

People

(Reporter: elreydetodo, Assigned: yuenhoe)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Keywords: student-project, Whiteboard: [read comment 141, 143 before commenting][workaround for saving multiple messages (bug 634720): see comment 153][delight])

Attachments

(3 files, 15 obsolete files)

8.45 KB, text/plain
Details
6.07 KB, patch
Details | Diff | Splinter Review
2.96 KB, patch
Bienvenu
: review+
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+

AFAIK Thunderbird is not able to drag and drop messages outside of the
application.  It should be possible to drop emails into the filesystem or into
text editors with predictable results.

Here is what I would like to see:
1. If I drag a message onto my desktop, it should make a file called
[subject].eml, which contains the exact code of the message.  Also, and I don't
know if this is yet possible, but Thunderbird should be able to open messages
ending with .eml just as Outlook Express or Outlook can.  Both of those clients
support this kind of drag and drop.
2. Also (and slightly less important), if you drop a message onto a text editor
like notepad (or I daresay MS Word), it should put the contents of the message
into the document.

Both of these are somewhat mentioned (though not very clearly) in bug 218587 and
bug 226312.

Reproducible: Always

Steps to Reproduce:
1. Select a message from a mail folder
2. Drag it to a folder or the desktop
3. Drag it to a text editor window

Actual Results:  
Nothing.

Expected Results:  
Should put make a file or place the contents of the email, depending on which
you are doing.
Why the message should be extended with a non standard .eml??
I think in this case is better to use .mbox that is a standard for mail messages.

The .eml files created by Outlook Express consist of the exact message source
put into a file which happens to have the .eml extension.  Any extension would
be fine, but this format makes the most sense.  I'm not completely sure, but I
think mbox format is just a series of messages in this format anyway.

Right now I export all of my emails to my filesystem on a quarterly basis for
archives.  To do this, I have to switch to OE because Thunderbird doesn't
support drag and drop.  It already supports saving files as .eml files, but I'd
have to save each of them individually.  There needs to be a way to save
multiple messages to this format at once, and drag and drop is probably the way
to go.

The advantage to using .eml though is that Outlook Express would also be able to
open the files if you sent them to a user who didn't use Thunderbird.

Also, Thunderbird should be able to open these files.  It has support for
opening saved files in the formats of .eml and .msg, but I can't get external
opening to work (as in double-clicking on a file and it opening in Thinderbird).
 This should be fixed, but I'll need to add another bug for it.
(In reply to comment #0)
> 1. If I drag a message onto my desktop, it should make a file called
> [subject].eml, which contains the exact code of the message.  

Seamonkey bug 59622.


> Thunderbird should be able to open messages ending with .eml 

It can open them, sort of, but not via drag-n-drop (seamonkey bug 171907).


> 2. Also (and slightly less important), if you drop a message onto a text
> editor[...] it should put the contents of the message into the document.

> Both of these are somewhat mentioned (though not very clearly) in bug 218587

218587 is *exactly* your item #2; it's quite clear.  Changing summary of bug to 
focus on item #1.


> bug 226312

Was about dragging attachments, duped eventually to bug 83803 which was fixed.
Severity: normal → enhancement
OS: Windows XP → All
Hardware: PC → All
Summary: Thunderbird needs better external drag and drop support → Support dragging messages to desktop / file-system window (e.g. Explorer)
*** Bug 273899 has been marked as a duplicate of this bug. ***
*** Bug 273858 has been marked as a duplicate of this bug. ***
(In reply to comment #1)
> Why the message should be extended with a non standard .eml??
> I think in this case is better to use .mbox that is a standard for mail messages.
> 
> 
Saving a message from the File/Save As menu item already saves the message with
an EML extension.  Drag/drop should do the same for consistency.
Drag to file system should be able to drag multiple messages.  Outlook Express
resolves multiple messages with the same subject being dragged at once by
appending a number in parentheses to the second and subsequent message.  This
seems a reasonable approach.
*** Bug 284603 has been marked as a duplicate of this bug. ***
*** Bug 301715 has been marked as a duplicate of this bug. ***
*** Bug 317985 has been marked as a duplicate of this bug. ***
The ability to drag and drop messages to the windows file system is something that would help my company greatly. I am forced to use outlook express because of this feature. I can use save as and it will save the message to any location. Why can't drag and drop basically perform the task of "save as"?

Here is an example of why it would be a good feature.

Every piece of correspondence has to be logged into the client file.
Built into our software is the ability to drag and drop e-mail into the client file and have it log an e-mail in automatically. Outlook express allows us to do that. But currently we have to save as and then drag it from where it is saved into the client file. It would eliminate a step.

Thanks in advanced,
John
*** Bug 341546 has been marked as a duplicate of this bug. ***
OSAF's Chandler project (http://chandler.osafoundation.org/) would be really excited to get this feature in Thunderbird. We're building a task/calendar/collaboration client. As we're not going to be an email client in the first release, we need a way for our users to get emails into their task list, and drag and drop is one obvious alternative. We have this working for Outlook, but not Thunderbird. :( Several of us OSAF'ers are Thunderbird users, btw.
(In reply to comment #13)
> OSAF's Chandler project (http://chandler.osafoundation.org/) would be really
> excited to get this feature in Thunderbird. 

So why don't you allocate a developer to work on this? You could even ask the MoFo for funds - they just got a truckload of money from Google.
It should be pretty easy to pick up the drop event and call our existing save selected messages code.

would probably have to tweak:

http://lxr.mozilla.org/mozilla/source/mailnews/base/src/nsMessenger.cpp#1004
Keywords: helpwanted
I'm not particularly skilled at working with Javascript (my language of choice is Python), but a few months ago I spent an afternoon attempting to get this working, because OSAF could really use the functionality.  Unfortunately, I ran into limits in my understanding of XPCOM.

What I came up with is that message drag and drop is using a different API than the drag and drop used for working with attachments, which supports file-promise drop sources.

It wasn't clear to me if the two drag and drop architectures are fully equivalent, and it seemed somewhat involved (but perhaps worthwhile) to adjust all message drag and drop code to use a different API.

In summary, once message drag and drop supports file-promises, I think it would be trivial to implement drag and drop of messages outside Thunderbird.
Oops, to be clear, I don't know that the existing architecture *doesn't* support file-promises, I just couldn't find any documentation of how to implement them, all the examples and documentation I found on file-promises related to the architecture used by the attachment drag and drop code (I wish I knew the appropriate terminology for all this XPCOM stuff).
QA Contact: front-end
The MIS manager here where I work would love to switch everyone over to Thunderbird, if only it supported drag-n-drop functionality.  She drags-n-drops hundreds of messages a day into a list of folders on her thumbdrive, depending on recipient.  She can't live without it, and she ain't gonna use Ctrl-S (I already tried that).

Is there any easy way to get this drag and drop functionality into Thunderbird?
so she wants each of the drag-dropped messages to be saved as a separate .eml file on the thumbdrive? Or does she want them to be concatenated into one mail folder?
(In reply to comment #19)
> so she wants each of the drag-dropped messages to be saved as a separate .eml
> file on the thumbdrive? Or does she want them to be concatenated into one mail
> folder?

She wants just one .eml file per email message.  Why?  Because this is the way Outlook Express does it.  But Outlook Express gives us so many problems... but I digress.  Yeah, one .eml file per message.
Yes I would like that too.  I don't want to use Outlook Express anymore but I need the drag and drop feature. 

Petra

 -Female Geek
Assignee: mscott → nobody
Yes, such a feature is very useful. why not implement it ?
** THIS FEATURE SHOULD NOT BE CONSIDERED AS OPTIONAL! *** It should be normal to be able to drag a message out of Thunderbird to the OS directory. Dragging to an application is not as crucial. Development should start with the simple ability to drag an email message from Thunderbird towards any folder in the operating system of the computer. Please VOTE for this feature, if you do not have an account, create one, it's super fast, an then come back and vote for this feature. I'm not a programmer (i wish i was) so i can't help much.
All my best to the person who will take upon himself to develop this for the credit of all TB users !!
thx
Marc

PS :  If you are working on a network with LOTS of folders to save emails to, the "save as" option is REALLY a drag !!
Same Problem here,
got to save 100 Mails/per Day. 
Always Hardcore!

PLEASE VOTE 4 this FEATURE
Flags: wanted-thunderbird3?
Yes please! This is really a good feature!
A Must Have!

Please Vote!
If you use a DMS and want to save/archive a document like a mail, you usually just drag and drop the document into the DMS vault.

Since Thunderbird cannot do this, it is likely that we have to switch to Outlook instead. Of course you can always use "Save as.." and then drag&drop the selected Mail, but nobody will do this! People just won't use the system for their mails. 

I would expect consistent behaviour, i.e. being able to drag&drop to filesystem / desktop / whatever other application.
marking wanted+
Flags: wanted-thunderbird3? → wanted-thunderbird3+
Yep, same here!
Want to get rid of MS Outlook..
really need drag & drop..
Whiteboard: [delight]
Yes Please I would also like this Drag and Drop feature in Thunderbird!!
I'm using SmartSave now https://addons.mozilla.org/sv-SE/thunderbird/addon/2887
Nice addon - works even better (for me) than drag & drop...
I don't think, that we will ever get this. After almost 6 years this feature was not impemented..., why should it be in the next few month?

Maybe this is way, some people still work with MS-Outlook, because some very nice feature are still missing on FF!
Summary: Support dragging messages to desktop / file-system window (e.g. Explorer) → Support drag-drop messages to desktop / file-system window (e.g. Explorer)
This should be absolute priority.
 
Being able to drag e-mails to file system folders (and also back into mail folders) is indispensible for serious work and absolutely so for private use (documentation, backup, filing...).
Most bizarre, Thunderbird can't even open it's own saved .eml files.

As long as this is not resolved, there isn't the slightest chance of Thunderbird becoming an alternative to Outlook.

p.s.: Thunderbird 3 Beta still can't.
"Most bizarre, Thunderbird can't even open it's own saved .eml files."

Yes, It can! Just choose Thunderbird to act as your default e-mail client.
Even if you already done that - do it again!

also see comment #32
If nobody else is interested I'd like to try addressing this issue :)
(In reply to comment #37)
> If nobody else is interested I'd like to try addressing this issue :)

Sure. Thanks, and good luck! :)
Assignee: nobody → yuenhoe
This is an assigned student-project from NUS for CS3108 08/09 Semester 2. Yuen Hoe, it'll be cool if you could post some progress (if any) for this bug.
Status: NEW → ASSIGNED
Keywords: student-project
Version: unspecified → Trunk
Gary : okay sure. I don't have anything presentable at the moment, still experimenting, but I think I'll have a dirty patch up soon. Will post it when thats done :)
Attached patch Preliminary (working) patch (obsolete) — Splinter Review
Preliminary patch tested to work on Linux (Gnome and KDE). Supports dragging and dropping one or more messages from Thunderbird to the desktop or to a file manager window. Dragging multiple emails will be dropped as multiple .eml files.

Can someone help me verify that this patch works also on Mac and Windows?
Also, I'm treading on a lot of unfamiliar ground here, so I'd really appreciate it if someone could help me take a quick look at my code and point out any problems / improvements I can make.

It's essentially a two-part patch. I've added a method to nsMessenger that allows saving of a mail message without popping a file-selector, and I've implemented the drag-and-drop functionality using the new method.

I'll be doing what I can to refine the patch code, so if someone can critique my code a little for me, that'll be great :)
Please tell a noob like me how to use/install this patch?
Attached patch (fixed) Preliminary patch (obsolete) — Splinter Review
I made a mistake in the post-drag cleanup code in the previous patch. Uploading fixed version. Sorry for the spam >.<
Attachment #367560 - Attachment is obsolete: true
looks very good, thx.
what i would love to see is a config option:
[x] replace space with "_" (cause space sucks on linux)
and a way to export the way someone likes the filename
[%YYYY%MM%DD-%FROM-%SUBJECT].eml 

thx for your patch
"a way to export the way someone likes the filename
[%YYYY%MM%DD-%FROM-%SUBJECT].eml"

see Comment #32
Attached patch Proposed patch (obsolete) — Splinter Review
Proposed patch.

Dragging multiple messages with exactly the same subject now produces multiple files with filenames appended with numbers. Plus some minor refinements.
Attachment #367563 - Attachment is obsolete: true
Attachment #367751 - Flags: superreview?(bienvenu)
Attachment #367751 - Flags: review?(mkmelin+mozilla)
(In reply to comment #45)
> looks very good, thx.
> what i would love to see is a config option:
> [x] replace space with "_" (cause space sucks on linux)
> and a way to export the way someone likes the filename
> [%YYYY%MM%DD-%FROM-%SUBJECT].eml 
> 
> thx for your patch

I think that is outside the scope of this bug. However if this fix gets checked in it should be trivial matter to create an extension to add those options.
doesn't work on windows. I get a + drag icon outside the app but nothing happens on drop.  Not sure how it works outside of app but I think it has to utilize the clipboard. I'm not sure if windows may need  initWithNativePath.
Can you do this using the O/S native implementation of drag and drop. Not sure but this may help.
http://mxr.mozilla.org/comm-central/source/mozilla/widget/public/nsITransferable.idl#78

The message attachments are dragged to o/s. Maybe this can give some insight.
http://mxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.js#1902
it goes thru nsDragandDrop.js but you may not need to do that if you can implement your own transferdata.
Phil: Thanks for the feedback and suggestions. I'll see what I can do to get it fixed. Now if only I have a Windows build to test it on...
Attached patch Windows fix (?) (obsolete) — Splinter Review
Attempted fix for Windows.

Basically added code that mimicked the drop attachment code (which works on windows, but NOT linux D:).

Would appreciate it if someone could try it out on windows and let me know the results :)
Attachment #367751 - Attachment is obsolete: true
Attachment #367751 - Flags: superreview?(bienvenu)
Attachment #367751 - Flags: review?(mkmelin+mozilla)
Keywords: helpwanted
Doesn't work yet, for windows XP.
However I was able to see the file appear in the temp dir although I last told you in irc I didn't even get that much.
works now after I removed the dragend handler. Dragend apparently was deleting the file before it was copied over.
But it doesn't do more than one file. it gives the forbidden icon.
dragend may not be needed. The temp file is overridden with a new drag operation. I changed the content of the temp file to make sure the newer drag operation was using the latest file.
Thanks phil. I built myself a windows build and am able to reproduce the problem now. What I find curious is I'm getting a lot more assertion failures in windows (that are unrelated to this fix) than I get on Linux. I wonder if an assertion firing in the middle of a drag would cause the drag to be construed as a failure - and thus raise the dragend event which deletes the file prematurely. I'll need to experiment and see.

I think the dragend cleanup is important though because it is possible to drag a lot of email out (for storage for example) and I'd say having a duplicate of every one of them sitting in the tmp folder isn't desirable =x
sid asked a good question on irc if the file write is asynchronous. It appears the write very well could be occurring on o/s time or thread.
I don't see a problem with leaving the file in temp folder but you may need to investigate.
Also maybe we have a mechanism to 'move' the file to final location instead of copying.
(In reply to comment #56)
> Thanks phil. I built myself a windows build and am able to reproduce the
> problem now. What I find curious is I'm getting a lot more assertion failures
> in windows (that are unrelated to this fix) than I get on Linux. I wonder if an
> assertion firing in the middle of a drag would cause the drag to be construed
> as a failure - and thus raise the dragend event which deletes the file
> prematurely. I'll need to experiment and see.

The firing itself shouldn't change any behavior, but the fact that there's a condition causing an assertion to fire could well be related to whatever problem you're seeing, especially if the assertion is coming from mailnews code.

> I think the dragend cleanup is important though because it is possible to drag
> a lot of email out (for storage for example) and I'd say having a duplicate of
> every one of them sitting in the tmp folder isn't desirable.

Agreed.
//    var tmp = new FlavourData(new nsFlavorDataProvider(), 0, 
//                        new Flavour("application/x-moz-file-promise", Components.interfaces.nsISupports));
//    aEvent.dataTransfer.mozSetDataAt(tmp.flavour.contentType, tmp.supports, i);
    aEvent.dataTransfer.mozSetDataAt("application/x-moz-file", tempDir, i);

the x-moz-file with the nsIFile as data can replace the x-moz-file-promise in windows XP.
But the other problems of non multiple files and the draggend problem still exists.
Hmmm that one didn't work on my windows 7, but then I commented out the x-moz-file-promise-url too. Enn has given me some pointers I'll try working on that a little later, hopefully I'll make some progress =x
This patch will add a testing window in the tools menu.
Drag anything, system-based files, folders, whatever.  This will show the types and data we get.
This revision enables selecting and copying.
Attachment #371073 - Attachment is obsolete: true
Attached file Mac compile error
Using the "Windows fix (?)" patch at:

https://bug227305.bugzilla.mozilla.org/attachment.cgi?id=368251

It might be just me, but I'm getting a compile error with this on the Mac.
(In reply to comment #61)
> Hmmm that one didn't work on my windows 7, but then I commented out the
> x-moz-file-promise-url too. Enn has given me some pointers I'll try working on
> that a little later, hopefully I'll make some progress =x

similar to bug 377621, for windows the following is needed
-text/x-moz-url 
-application/x-moz-file-promise-url",
-application/x-moz-file-promise, with 'null' for data.
the data for the first two is in the format as the attachment code:
mailbox://<path-to-folder>?number=<number-folder>&filename<our-created-filename>

the windows code makes a stream object based on the protocol and windows does the rest.

In GTK we need backend code to read these flavours and do the file copying there.

In MAC I don't know what works. I don't know if attachments DND works if so this should do it.

Lim if you can get these coded here then the other bug needs coding for GTK backend.

the other flavor needs to stay as is for dnd inside the app.

Other copy code here and dragend won't be needed.
> mailbox://<path-to-folder>?number=<number-folder>&filename<our-created-filename>
 
errata and should be checked out (going from memory):
mailbox://<path>?number=<messagenumber>&filename=<ourname>&type=plain/text
don't know if the content type is needed.
(In reply to comment #64)
> Created an attachment (id=373345) [details]
> Mac compile error
> 
> Using the "Windows fix (?)" patch at:
> 
> https://bug227305.bugzilla.mozilla.org/attachment.cgi?id=368251
> 
> It might be just me, but I'm getting a compile error with this on the Mac.

Thanks Gary. The snippet you posted doesn't seem to contain the error message though. Do you think you can post the full compile message? Or better yet, pipe stderr to a file and post that :P

Phil: x-moz-url is actually not needed. Only the latter pair is required to drop one file in Windows.

I'm not sure yet, but the Windows code supporting x-moz-file-promise looks rather hard-coded to support one file =/ Anyhow that way of specifying seems a little broken to me anyway - setting a null object as file promise. I'm actually leaning towards the idea of unifying the behaviour of the Windows code with that of the Linux code - ie specifying url's causes the url target to be dropped. I think this behaviour makes sense, and will permit this bug to be fixed in a reasonably sensible manner.

Granted it doesn't solve the larger problem of dropping data from XUL apps directly to file(s) on the system, but I think that's a larger and stickier problem that involves more than mail messages, and probably deserves it's own bug.
(In reply to comment #67)
> Phil: x-moz-url is actually not needed. Only the latter pair is required to
> drop one file in Windows.

double check this.  I can't get it to work without it, at least in the similar dnd code in attachments, msgHdrViewOverlay.js, and the windows backend code requires this flavour to set up the windows format needed for stream creation which is used by windows to create the file.


http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/windows/nsClipboard.cpp#202
(In reply to comment #64)
> Created an attachment (id=373345) [details]
> Mac compile error
> 
> Using the "Windows fix (?)" patch at:
> 
> https://bug227305.bugzilla.mozilla.org/attachment.cgi?id=368251
> 
> It might be just me, but I'm getting a compile error with this on the Mac.

Yuen Hoe, no more compile error now, but the drag n drop isn't working. Nothing happens when I drag a message and drop onto the desktop.

Mac self compiled build - Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090425 Lightning/1.0pre Shredder/3.0b3pre
In bug 377621, I've been stumping to do GTK in backend and roc agrees, so until that one is done this one can't do much.
Eventually it would be nice to have everything just use these flavors and no other temp file creation/deletion etc.
-application/x-moz-file-promise-url",
-application/x-moz-file-promise

windows needs -text/x-moz-url but that may be an error in the backend code for windows.
Blocks: 491239
Attached patch d&d one eml to winXP O/S (obsolete) — Splinter Review
This uses Lim Yuen Hoe code and refines it to basic essentials needed for windows XP.  Needs confirmation on Mac and Vista.

Needs backend work on GTK to match this front end.

Tested to work for local folder messages and IMAP.
Attachment #368251 - Attachment is obsolete: true
drops a something on the test window and see what flavor is transferred.
this version shows the file name if there is a x-moz-file flavor
Attachment #371155 - Attachment is obsolete: true
Attached patch revised to diff to tip (obsolete) — Splinter Review
diff to tip
Attachment #378732 - Attachment is obsolete: true
sorry, this works but after review, I'll need to do some clean up saveMessageToFile isn't needed. Ok in this condition to patch and test.
Attached patch cleaned up (obsolete) — Splinter Review
cleaned up I think, works as expected in windows XP IMAP and local folders. Only one message. Multiple file drag should have new bug.
Attachment #378739 - Attachment is obsolete: true
found more cleanup.  Again hoping this cleans it up. Patch still working order.
Attachment #378753 - Attachment is obsolete: true
Yeah, this is pretty much the patch I have as well. See bug 458159 comment 12 for why it won't work with Vista's Explorer right now.
Attachment #378784 - Flags: review?(mkmelin+mozilla)
per Sid's recommendation, adding filename length limit especially since this operation doesn't have control over changing the name like filepicker.

This doesn't work on mac so we still need a decision on making things work in backend for GTK and Mac to mimic windows.
Attachment #378784 - Attachment is obsolete: true
Attachment #379044 - Flags: review?(mkmelin+mozilla)
Attachment #378784 - Flags: review?(mkmelin+mozilla)
Looks good given the premises.

I won't worry too much about linux/mac side yet though, I think multiple drag is integral to this bug (it says drag-drop messageS too :P), so I wouldn't consider this issue properly resolved until we have that working too - at least on windows. I'm sure most users would agree with me.

Sorry for my long disappearance btw =( Had been held up by lotsa things, notably Internet troubles~
(In reply to comment #78)
> Created an attachment (id=379044) [details]
> more cleanup and added filename length limit
> 
> per Sid's recommendation

I was referring to this bit: <http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/windows/nsDataObj.cpp#363> -- you'll need to chop it down further to 124, so that the ".eml" also fits.
Attachment #379044 - Flags: review?(mkmelin+mozilla)
Comment on attachment 379044 [details] [diff] [review]
more cleanup and added filename length limit

I can't test this since dnd to desktop isn't working on linux. Anyway, some comments:

>-  for (let i in messages)
>+  var ios = Components.classes["@mozilla.org/network/io-service;1"].
>+                    getService(Components.interfaces.nsIIOService);

Please always put the dot on the next line, and align with dots, like

var ios = Components.classes["@mozilla.org/network/io-service;1"]
                    .getService(Components.interfaces.nsIIOService);


>+    var subject = messenger.messageServiceFromURI(messages[i])
>+                                .messageURIToMsgHdr(messages[i]).mime2DecodedSubject;

Align with dots.

>-  aEvent.dataTransfer.effectAllowed = "copyMove";

So is there something replacing this?

>-  aEvent.dataTransfer.addElement(aEvent.originalTarget);
>+    aEvent.dataTransfer.mozSetDataAt("text/x-moz-url",msgUrls.value.spec, i);
>+    aEvent.dataTransfer.mozSetDataAt("application/x-moz-file-promise-url", msgUrls.value.spec + "&fileName=" + uniqueFileName, i);

Please wrap @80

>+function suggestUniqueFileName(identifier, type, existingNames) {

Add doxygen/javadoc comment for the method? Also, typo with |existingNames|

>+  var suggestion = GenerateValidFilename(identifier, type);
>+  var suffix = 1;
>+  while(true) {

Space before (

>+    var exists = false;
>+    for (var i = 0; i < existingNames.length; i++) {
>+      if (existingNames[i] == suggestion)
>+        exists = true;
>+    }
>+    if(!exists) break;

Space before ( and put break on a new line.

>+    suggestion = GenerateValidFilename(identifier+suffix, type);
>+    suffix++;
>+  }
>+  return suggestion;
>+}
Blocks: 501054
No progress here =/ I'm gonna try again. I think I need some opinions on this one. As far as I and Phil could tell when we worked on this, we could not find a way to get this (multiple drag) to work on Windows using the existing drag types and javascript API. So I guess what I need to do is pick a sensible way to do this on the API level and go down to underlying implementation and tweak it to support it.

So I could use some thoughts on what the code should look like at the API level. I could take Phil's patch and try to make it work - would that be a good idea?
(In reply to comment #82)
> So I could use some thoughts on what the code should look like at the API
> level. I could take Phil's patch and try to make it work - would that be a good
> idea?

It'll be good to see what you propose.
I think it would be a great feature, it is very useful on the windows platform.
Anyhow, an application should not monopolize it's data, and allow the user (and other systems) to retrieve the content. Thunderbird is handling EML format, that is good, because standard, but it should enable drag&drop (to start with 1, later multiple) of an email to the desktop, just like for attachments.
The reverse way (drag & drop e-mails from other windows like Windows Explorer into certain mailbox folders) would be also very helpful in order to simplify the import process of mail files (eml).
I have been trying to find ways round this as well.  Our Software enables email logging as well so we are stuck using "Very Bleak" Outlook.  This should be a standard feature and I think.

Regarding the format, it probably should be .eml but there could always be an option in "Options..." to drag and drop them as .mbox instead of .eml (FORMAT PROBLEM SOLVED!!!)
(In reply to comment #79)
> I won't worry too much about linux/mac side yet though, I think multiple drag
> is integral to this bug (it says drag-drop messageS too :P), so I wouldn't
> consider this issue properly resolved until we have that working too - at least
> on windows. I'm sure most users would agree with me.

In windows, maybe other platforms, multiple messages won't be cured in 'front-end' code that I can tell.

If that's the case we should just do the one message here. Multiple message loop should be left in. It just won't be working yet.  Another bug can be filed under 'core' to fix the dataObjectCollection that controls multiple transfer items.

Backend core work is under Firefox regime and may not get done soon enough for TB.
(In reply to comment #89)
> If that's the case we should just do the one message here. Multiple message
> loop should be left in. It just won't be working yet.  Another bug can be filed
> under 'core' to fix the dataObjectCollection that controls multiple transfer
> items.
> 
> Backend core work is under Firefox regime and may not get done soon enough for
> TB.

Yeah, I guess that's all we can do for now. I'm told that core stuff isn't gonna land anytime soon since it just got a release with firefox 3.5, so it looks like this bug will drag on again =(

I think we should go ahead and file that bug with core because it doesn't look like this one will get accepted as it currently is. We could keep code that attempts to address multiple drag as a stub but we'll never know if the stub would be correct until core figures out how they want to implement multi-drag.

And by the way, in case it isn't clear, I'm not actively working on this anymore, since as far as I'm concerned the problem is at core level. If anyone else would like to give fixing this without hacking core a go, please feel free.
Just a question: what is the status now?
Can we at least expect to drop a mail out of thunderbird to the desktop (in windows), if just one at a time, that's ok voor now.
Is it going to be fixed? Does it help to sponsor this?
Attached patch incorporates comments (obsolete) — Splinter Review
This does one message at a time for windows only. Linux backend fix is in the works but MAC is unknown at this time.
This is just a revamp of Lim Yuen Hoe windows patch. Credit any checkins to him.
Not sure if all reviews needed are marked, but Magnus needs to look over.
Attachment #379044 - Attachment is obsolete: true
Attachment #396154 - Flags: review?(mkmelin+mozilla)
Summary: Support drag-drop messages to desktop / file-system window (e.g. Explorer) → Support drag-drop single message to desktop / file-system window (e.g. Explorer)
(In reply to comment #90)
> And by the way, in case it isn't clear, I'm not actively working on this
> anymore, since as far as I'm concerned the problem is at core level. If anyone
> else would like to give fixing this without hacking core a go, please feel
> free.

Deassigning then. Thanks for your help, Yuen Hoe. Others, please feel free to take this bug.
Assignee: yuenhoe → nobody
Status: ASSIGNED → NEW
Enn should have been CCed all along...

Can someone file that core bug?
Comment on attachment 396154 [details] [diff] [review]
incorporates comments

Punting to bienvenu as i don't have windows to test.

5 lines have trailing spaces
Attachment #396154 - Flags: review?(mkmelin+mozilla) → review?(bienvenu)
(In reply to comment #94)
> Can someone file that core bug?

I wouldn't know how to demonstrate a core bug until this one lands.
I was going to at that time.
Blocks: 270292
Comment on attachment 396154 [details] [diff] [review]
incorporates comments

thx for the patch.

this part horks the patch:

-/** ***** BEGIN LICENSE BLOCK *****
+ ***** BEGIN LICENSE BLOCK *****

can you use let instead of var for the local var names?

The multiple name protection code never runs, right, because of some toolkit bug? So that's probably worth a comment in the code.

The while (true) loop is awkward - one possibly alternative would look like this:

  let suffix = ""
  let suggestion;
  let exists;
  do {
    exists = false;
    suggestion = GenerateValidFilename(identifier+suffix, type);
    for (let i = 0; i < existingNames.length; i++) {
      if (existingNames[i] == suggestion)
        exists = true;
    }
    suffix = suffix == "" ? 1 : ++suffix;
  } while (exists);
  return suggestion;

though that's untested and I don't know if there's a better way of doing the suffix = suffix == "" ? 1 : ++suffix; line...
Attachment #396154 - Flags: review?(bienvenu) → review-
was this supposed to support copying multiple messages to the desktop somehow? There's a comment to the effect that it happens one at a time, but on windows, at least, I just get a can't drop mouse cursor when I attempt to drag+drop multiple messages.

windows checks for an attempt to overwrite an existing file on drop; do the other desktops do the same?
(In reply to comment #97)
> The multiple name protection code never runs, right, because of some toolkit
> bug? So that's probably worth a comment in the code.

Yes, and please reference the bug number in question from that comment, so that people can learn what the current state of it is when reading or testing this code in the future.
multi drag causes crash in TB so the loop is removed so now it acts like attempts to drag multiple attachments.  Only one is completed. Best we can do at this point. If there is a way to prevent multi drags then advise so I can fix this and the 'dnd attachment' problem.

The file has notes about changing to multi-drags when that is possible in backend, including commenting out the loop and leaving in suggestUniqueFileName(). I also changed that function to have more logical flow.
Attachment #396154 - Attachment is obsolete: true
Attachment #397417 - Flags: review?(bienvenu)
Comment on attachment 397417 [details] [diff] [review]
removes multi-message drag and fix per r comments

forget it can't eliminate multi drag because we need it for draging inter-app as in folder to folder.
Attachment #397417 - Flags: review?(bienvenu)
Cleaned up Phil's previous patch. I just updated to tip and the patch works fine - multidrag works within thunderbird but not to desktop, but single drop works for both. Windows only at the moment.

I'd be happy to work on this again once core is able to support multi-drag to desktop.
Attachment #397434 - Flags: review?(bienvenu)
Blocks: 513464
No longer blocks: 270292
Thx for the patch - can you add a comment to the effect that we won't currently be doing drag drop of multiple messages to the desktop and cite the bug (bug 513464, I believe)


I tried the patch and it worked well, except for the first time I tried it, when TB locked up after testing multiple msg drag to the desktop, getting the "no drop" cursor, and then dragging over the folder pane and getting a frozen no drop cursor. After that, both TB and Firefox were locked up, which was very strange. I wasn't able to reproduce that.
Comment on attachment 397434 [details] [diff] [review]
Proposed patch for 1 message on Windows

>+  for (let i in messages) {
>+    messenger.messageServiceFromURI(messages[i])
>+			 .GetUrlForUri(messages[0], msgUrls, null);
>+    var subject = messenger.messageServiceFromURI(messages[i])

 messages[0] should read messages[i]

nit '.' should vert align
Attached patch Addresses comments (obsolete) — Splinter Review
Updated as per comments.

I am unable to produce the lockup bienvenu mentioned at all.
Attachment #397434 - Attachment is obsolete: true
Attachment #400325 - Flags: review?(bienvenu)
Attachment #397434 - Flags: review?(bienvenu)
>+    messenger.messageServiceFromURI(messages[i])
>+			 .GetUrlForUri(messages[0], msgUrls, null);

don't forget to align the '.'. We also may have a requirement to use spaces in lieu of tabs and that may have caused the alignment problem here. There may be other tabs that need converting to spaces in the patch, so you may want to review that. 

    messenger.messageServiceFromURI(messages[i])
             .GetUrlForUri(messages[0], msgUrls, null);
Hope the alignment issue is done this time. Not familiar with the editor I use in windows =/
Attachment #400325 - Attachment is obsolete: true
Attachment #401705 - Flags: review?(bienvenu)
Attachment #400325 - Flags: review?(bienvenu)
Attachment #401705 - Flags: review?(bienvenu) → review+
Comment on attachment 401705 [details] [diff] [review]
(hopefully) fixed aligning issues

looks OK to me...thx for the patch.
Running with this, I've seen the hang I mentioned earlier a couple more times - it kills both Thunderbird and Firefox, which is wild. Without this patch, I don't see an issue. So I don't think this is good to land at the moment. I'm running Windows 7. If I break into the debugger, Thunderbird is still in its drag drop code. I don't know what Firefox is doing, since it's a release build.
Attachment #401705 - Flags: review+ → review?(bienvenu)
Comment on attachment 401705 [details] [diff] [review]
(hopefully) fixed aligning issues

I'm going to retract my r+ until someone can figure out the hang on drag drop. Can anyone reproduce it with this patch? It might be Windows 7 specific...
(In reply to comment #110)
> (From update of attachment 401705 [details] [diff] [review])
> I'm going to retract my r+ until someone can figure out the hang on drag drop.
> Can anyone reproduce it with this patch? It might be Windows 7 specific...

Maybe you can isolate which dragovers may be causing it if that's the case. Can you trace the same drag path with attachments and see if that does it as well?

I've only had problems dragging over the tabs or (tab bar)? of Firefox. Same with attachments Bug 514148. complete freeze as the bug states. This happens regardless of incoming server is IMAP or local store.
firefox tab bar is a very likely suspect.
(In reply to comment #112)
> firefox tab bar is a very likely suspect.

David, can you r+ this if you can comfortably isolate it to same STR as attachments (which we already have in place).
I can r+ it, but I wouldn't land it with it being so easy to hang both apps.
Attachment #401705 - Flags: review?(bienvenu) → review+
Yes I suspect it has to do with Firefox. I've never encountered this issue running on Windows 7 RC - which isn't my primary OS by a long shot and thus doesn't have Firefox installed.
Depends on: 514148
I installed firefox and am able to reproduce the lockup 100% by dragging a message into the firefox tab bar. Dragging it around anywhere else doesn't doesn't seem to create anymore problems. I'll do some probing into firefox code tomorrow and see if we could work around this issue.
Attachment #401705 - Flags: approval-thunderbird3+
Assignee: nobody → yuenhoe
Status: NEW → ASSIGNED
Keywords: checkin-needed
Target Milestone: --- → Thunderbird 3.0rc1
Removing checkin-needed until I've spoken with David to clarify some of the comments about the hangs.
Keywords: checkin-needed
the next point release of Firefox will have the hang fixed (the 1.9.1.4 based release which will be out before TB 3) and we'll get the fix into 1.9.2 as well.
Hmmm, so is this going to be checked in after all?
Keywords: checkin-needed
(In reply to comment #119)
> Hmmm, so is this going to be checked in after all?

You need to use the checking-needed keyword for that to happen :-)
Attachment #397417 - Attachment is obsolete: true
Checked in: http://hg.mozilla.org/comm-central/rev/1896d6bbd5aa
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Depends on: 528713
Hi, nice to see the drag'n'drop feature is available... But... Can someone please help how to retrieve the drag'dropped object in a C# application?

I've already coded sth. like this, but I just don't know how to access the data correctly...

        private void mTV_DragDrop(object sender, DragEventArgs e)
        {

            /* DragDrop from Thunderbird */
            if (e.Data.GetDataPresent("text/x-moz-message"))
            {
                Object message = (Object)e.Data.GetData("text/x-moz-message");
                Object url = (Object)e.Data.GetData("text/x-moz-url");
                /* how to access the data here? */
            
            }
        .....


Thanks mates!
Bug 484667 is now checked in so with that patch an external app can retrieve a file. Not sure about c# or platforms other than windows but it will be registered as CF_HDROP or  'application/x-moz-file' here's sample data from drop. file is temp file that is deleted after 500ms so you need to open it after drop within that time. Let us know progress and we can add litmus test maybe to represent your results.

Items count = 1
*********************************
Item 0: type count = 2
------------------------------
     0: type = "application/x-moz-file" data type = "object"
[xpconnect wrapped nsISupports]
  nsILocalFile
  nsILocalFileWin
  nsIFile
    E:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\FW Metro Type TL.eml
  nsIHashable
  nsISupports
------------------------------
     1: type = "text/x-moz-url" data type = "string"
mailbox:///E|/Documents%20and%20Settings/Administrator/Application%20Data/Thunderbird/Profiles/zctn8und.Office/Mail/Local%20Folders/Inbox?number=275118403
Unforunatley, I can't find any "application/x-moz-file" data in the available object. The following "dataformats" are available in the dropped object:

text/x-moz-message
text/x-moz-url
FileGroupDescriptor
FileGroupDescriptorW
FileContents
UniformResourceLocator
UniformResourceLocatorW
application/x-moz-file-promise-url
FileDrop
FileNameW
FileName
Preferred DropEffect
DragImageBits
DragContext

I have extracted each of them as memory stream and I can see only IMAP:// - paths, not a local file path,e.g.:
imap://<account>%40googlemail%2Ecom@imap.googlemail.com:993/fetch...
(In reply to comment #124)
> FileGroupDescriptor
> FileGroupDescriptorW
> FileContents

The FileGroupDescriptor and FileContents are used to get the stream.
see http://msdn.microsoft.com/en-us/library/bb776902%28VS.85%29.aspx#CFSTR_FILECONTENTS

> FileDrop
> FileNameW
> FileName

I'm not familiar with these but they should be CF_HDROP which data is the path to the temp file that was saved. It will be deleted after 500 ms in order to give programs time to open it.

We don't support multi files yet.

I'll post a pic of data that windows sees on this drop.
Bug 338478 comment 2 for program to inspect the drop data.
Hello,

maybe it's because I'm drag'dropping the mail from an IMAP account, not a local folder... But I've used ClipSpy and I can definitly say that the path to the temporary email is not within the dropped object data.

This is a screenshot of ClipSpy and the data delivered by the dropped mail:
http://img96.imageshack.us/img96/4551/2312.png

Regards and thanks so far!
this patch landed awhile ago. The patch that enables this in comment 123 is 12/20/09 so you need a nightly of at least 12/21.  then your CF_HDROP will have valid data you can use.
Not sure about what Status "Resolved Fixed" says.. but anyway.. Thunderbird v3 I think is the final solution.. just drag & drop like in Outlook Express...
SUGGESTIONS:

1) Instead of deleting file in temp directory after 500ms, why not delete files on app shut down.

2) Needs to automatically rename files in the temp directory by adding a number to end of file name if file name already exists.

3) Should also have the file contents in a stream, Windows Mail and LiveMail store it in "Internet Message (rfc822/rfc1522)" and the message text body (not HTML) in "CF_UNICODETEXT" and "CF_TEXT".  This would make Thunderbird compatable with other software that use these products.  Outlook is just a different entity all together which only makes sense to the "left arm doesn't know what the right arm is doing" people at Microsoft ("CF_UNICODETEXT" and "CF_TEXT" are empty in Outlook, go figure!).  Already "FileContents" exists within the Thunderbird structure, but it is empty, maybe set this as well.

4) Definately should do multiple files, if so see suggestion 1 above (if many files could take more than 500ms to process), also would need to implement suggestion 2 above.  Not a problem as "CF_HDROP" is actually for a file list, being multiple files.

On another note, filling in CF_HDROP is good because it makes it compatable with apps that can accept a drag & drop explorer file.  CF_TEXT would allow you to drop the entire message text into Word, Notepad, etc.
ANOTHER BUG !!!!!

Draging and dropping email attachments has the same "CF_HDROP" bug in that the parameter is empty.
Blocks: 542038
YET ANOTHER BUG !!!!

The drag handler in Thunderbird is somewhat broken as apps with components that interface with IShellFolder work fine with Outlook, Live Mail, etc. but don't work with Thunderbird.  The failure is when there is a drop and IShellFolder.Drop is called when dropping a Thunderbird email or attachment on it.
Above bug is Windows Vista only by the way
We have a client who does extensive drag and dropping all throughout the day, they receive orders and file the attachments. They have a small number, say 10 in a course of a day of 200 + files being filed that end up being 0KB. We've confirmed that 1, the attachments are fine in thunderebird, 2, we've asked they open the attachment first, to assure tb has downloaded it completely. 

Regardless of that random messages they drag out are 0kb, if they drag them again they stay 0kb, but they can open them directly or use the save as dialog to file them. 

Windows Vista Business is being used and there are 3 staff members doing the same job on different system that we've confirmed the problem with.

Keith
(In reply to comment #134)
What version are they using. You are saying they drag the attachments to a folder or desktop?

Bug 458159 is as you described but fixed in ver 3
There was another one too i saw that was fixed related to space in file names causing this. But some of the files that have done this are efax files, so the nameing convention, while it has spaces, can't be at full fault since peer emails work.

TB 3.0.4 right now. Every version of 3 does it. 

Keith
Sorry, they drag to a folderes, usually a network folder. Though y ou go back and drag the same file to the desktop and you get a 0kb file. It does it conistantly to the specific messages that it does it to the first time. So hopefully there is something to find with these messages.
I can't reproduce it but I'm on XP. It would be good if you could tell the file type and sizes of the one that works and the one that doesn't and if it is repeatable with the same two files (one working, the other not).

(In reply to comment #132)
> work with Thunderbird.  The failure is when there is a drop and
> IShellFolder.Drop is called when dropping a Thunderbird email or attachment on
> it.

Can you file a new bug.
(In reply to comment #138)
> I can't reproduce it but I'm on XP. It would be good if you could tell the file
> type and sizes of the one that works and the one that doesn't and if it is
> repeatable with the same two files (one working, the other not).
> 
> (In reply to comment #132)
> > work with Thunderbird.  The failure is when there is a drop and
> > IShellFolder.Drop is called when dropping a Thunderbird email or attachment on
> > it.
> 
> Can you file a new bug.

For me it is any attachment file or email in Vista, our XP and Windows 7 machines work fine.
(In reply to comment #138)
> I can't reproduce it but I'm on XP. It would be good if you could tell the file
> type and sizes of the one that works and the one that doesn't and if it is
> repeatable with the same two files (one working, the other not).
> 
> (In reply to comment #132)
> > work with Thunderbird.  The failure is when there is a drop and
> > IShellFolder.Drop is called when dropping a Thunderbird email or attachment on
> > it.

As an example download the examples at http://www.jam-software.com/shellbrowser_delphi/Samples.zip and run the JamExplorer.exe, it works fine for dragging Thunderbird emails and attachments using XP & Windows 7 but will not work for Vista (it interfaces with IShellFolder).
> 
> Can you file a new bug.
Please no more bug-spam here. This bug won't be reopened and your comments won't be noted.

You should only post new comment to reference the new bug number filed in case anyone on cc list wants to follow it.
Sorry for asking, but how come that this is "resolved" but still not present in TB 3.1.10?

Also in comment 129 "just drag & drop like with Outlook Express in TB3" doesn't seem to work.

Anyway, is there already a way to enable this in the latest TB version?

Thanks already
David.P
FIXED means the patch worked sufficiently for cases for which it was designed to fix. Which means this bug will not be reopened, and if you still have failures you should seek an open bug report, or file a new one.

xref files created by Justin - which need comments and help from other people to confirm:
Bug 567354 - Drag drop emails or attachments to IShellFolder interface in Windows Vista bug
Bug 581940 - Drag and Drop email to desktop omits the eml (.eml) extension
Whiteboard: [delight] → [read comment 141, 143 before commenting][delight]
Sorry I still don't understand what the state of this "patch" is. Has the "drag message to desktop as *.eml" feature been incorporated in TB (which version) -- or not yet?
I just ran a few tests on Daily (yeah, yeah, breakage and all doth occur) and a lot of the original problems are resolved.

1)  I can drag and drop to a [b]folder[/b] using a file manager application (in Windows, for example, it worked in both Explorer and my personal FM of choice, xplorer^2) as long as the directory you seek to write to is not protected.

2)  Dragging and dropping to a third-party text editor (notepad++) works fine.  Dragging and dropping to notepad works with single emails.  Word 2010, though, did not integrate the email(s) into the new blank document, but just linked to it/them.

3)  I was able to drag and drop 7 emails at one time to both FM locations as well as text editors.  As for FMs, it just created .eml source copies of each email.  For the text editors, notepad only displayed the first email in the list being dragged and dropped, creating it in .eml format in a temp directory and then loading it in notepad.  In np++ it opened 7 different documents, each with its own email in it.

Note - test conducted in Windows 7 x86_64, running Thunderbird Daily 10a.  Tests consisted of dragging 7 emails from a folder in Tb to 1)  Notepad  2)  notepad++  3) Desktop  4)  FM open to desktop  5) Windows explorer opened to desktop
Depends on: 766073
The problem is NOT "RESOLVED FIXED", as appears in the problem I reported in Bug 766073, that someone (Alice0775 White) duly mentioned as blocked by this Bug 227305.
Versailles, Tue 02 Oct 2012 22:06:00 +0200
Sorry Alice I didn't see your msg right above... stupid me
Versailles, Tue 02 Oct 2012 22:26:40 +0200
Dragging messages from TB to Windows Explorer or Notepad++ FAILS
~--~--~--~--~--~--~--~--~--~- ~--~--~--~--~--~--~--~--~--~--~--~
(In reply to John L. Galt from comment #145)

On Sat 16 Nov 2013 15h GMT in Windows 7 64bit Ultimate with TB24.1.0:

Dragging ONE message from TB message pane to a "C:\Temp024" folder in Windows Explorer showed Bug 766073 (the .eml file created was ALTERED in its contents, and accordingly WRONGLY DATED). Attempting to drag MULTIPLE messages at one time displayed a FORBIDDEN icon when hovering the destination folder.

Dragging ONE file (let's call it "Msg1.eml") to Notepad++ does open the file in Notepad++, but dragging a second one makes Notepad++ display « the file "Msg1.eml" doesn't exist anymore ». Dragging MULTIPLE files acts accordingly: the 1st file gets open but the next ones fail.

In short, dragging messages from TB to Windows Explorer or Notepad++, while working at 1st glance, is too unreliable for serious use; and as "Alice0775 White" wrote in her two messages (h123 and h1) posted on the same second (2012-09-01 01:15:28 PDT) on their two pages, Bug 227305 is blocked by Bug 766073.

So I suggest to change the bug 227305 status from RESOLVED FIXED to REOPENED (I recall that this bug makes impossible to replace Outlook Express with TB for serious handling of email).

Versailles, Sat 16 Nov 2013 17:24:20 +0100
(In reply to Michel Merlin from comment #148)

Michel, thanks for caring how to improve TB and filing your observations, which is generally appreciated :) There are plenty of things that could need improvement, and different users worry about different things, so it's hard to pick priorities given that TB is now mostly maintained by volunteers (everyone welcome to assist!). I've replied to Michel's core issue in his bug 766073, comment 2.

However, pls observe the public notification on Whiteboard field of this bug: Per Wayne's Comment 143, who is a long standing volunteer bug triager like me, we kindly ask all of you to respect our workflows here on bugzilla.mozilla.org:

(In reply to Wayne Mery (:wsmwk) from comment #143)
> FIXED means the patch worked sufficiently for cases for which it was
> designed to fix. Which means *this bug will not be reopened*, and if you still
> have failures you should seek an open bug report, or file a new one.

It is the custom here that we don't usually reopen old bugs unless they fail shortly after landing and are actually backed out again. Instead, we prefer to deal with outstanding issues in fresh bugs :)

Practically, this means what it says, for any issues that are still seen, pls avoid commenting here (linking to the followup bugs is welcome). Pls observe this advice for your own benefit: Comment 150 on a closed bug filed 2003 and fixed 2009 (4 years ago) is unlikely to get any attention, simply because the bug is closed, and nobody wants to go through 150 comments to see if there's anything unaddressed that still needs attention.

Instead, use BMO search to see if your problem has already been filed in a bug which is still OPEN (e.g. Unconfirmed, New, or Assigned). If not, pls file a new bug. Please limit yourself to exactly *one* small issue per bug pls! Bugs with multiple issues (even around the same topic) are much harder to understand and work on so they are unlikely to be fixed and often just languish around. I'm not denying that due to limited manpower, it can happen to good and actionable bugs, too ;)
Problem hidden behind administrative convolutions and broken comparisons
~--~--~--~--~--~--~--~- ~--~--~--~--~--~--~--~- ~--~--~--~--~--~--~--~--
"Thomas D." 2013-11-16 10:19:42 PST, while spending a lengthy message fighting the last line of my post (that suggested REOPENED) with convoluted administrative procedures that would stall any initiative, you ignore the core of that message: the 4 lines demonstrating that the RESOLVED FIXED was a WRONG decision based on a too fast and MISTAKEN evaluation of the problem.

And you ask me to read Comment 150 (with a broken link BTW) in a 10-y old thread closed 4 years ago, instead of bringing a real answer (do you only have one?) to the thread right under your eyes.

Hard to imagine more efficient way to convey your real intentions to not only stall Thunderbird but make it regress.

Versailles, Sat 16 Nov 2013 23:55:20 +0100
I realize that if the "Comment 150" link looked broken hence probably mistaken it was because actually anticipated. Yet it remains irrelevant. And I didn't mention your mentioning "BMO search" without even bothering to tell what this is and to link it (http://www.google.com/search?q=BMO+search showed nothing relevant).
Versailles, Sun 17 Nov 2013 00:08:35 +0100
Depends on: 939519
This bug has been resolved "FIXED" at the time in the normal course of our agreed and established workflows (as explained in comment 143 and comment 149); it's also VERIFIED FIXED because per current bug summary, "Support drag & drop of single message..." has been implemented and basically works. 

However, this does not imply that *every aspect* of this feature is working correctly or there's nothing to be improved. It's possible that there are bugs in the implementation of this bug 227305, and we're not saying all is perfect wrt drag & drop of single messages. However, any outstanding issues or suggestions for improvement require *new bugs* which will allow more efficient workflow of addressing them without the burden and clutter of 150 old comments and 18 old patches. Such followup bugs should be added to the "Depends on" field of this bug 227305, and will be analysed and fixed IF there are volunteers with the right set of skills, time, and will/priorities to analyse and fix them.

(In reply to Michel Merlin from comment #148)
> Dragging ONE message from TB message pane to a "C:\Temp024" folder in
> Windows Explorer showed Bug 766073 (the .eml file created was ALTERED in its
> contents, and accordingly WRONGLY DATED).

Bug 766073 covers several aspects which need analysis and dissection (to be done in bug 766073, not here).

I extracted Bug 939519: When saving/exporting messages as .eml files, should use date/time of internal "Date:" MIME header for "Modified" timestamp property of the file (not the date/time of exporting)

> Attempting to drag MULTIPLE
> messages at one time displayed a FORBIDDEN icon when hovering the
> destination folder.

Pls note that this bug 227305 (per current headline aka summary) is explicitly only about drag & drop of one *single* msg to target file system. Drag & drop of *multiple* messages (currently not possible) is bug 634720.

> Dragging ONE file (let's call it "Msg1.eml") to Notepad++ does open the file
> in Notepad++, but dragging a second one makes Notepad++ display « the file
> "Msg1.eml" doesn't exist anymore ». Dragging MULTIPLE files acts
> accordingly: the 1st file gets open but the next ones fail.

That looks much like Bug 927694. If not covered there, pls open a new bug with its own set of:
Steps to reproduce, Actual Result, and Expected Result.

> In short, dragging messages from TB to Windows Explorer or Notepad++, while
> working at 1st glance, is too unreliable for serious use; and as "Alice0775
> White" wrote in her two messages (h123 and h1) posted on the same second
> (2012-09-01 01:15:28 PDT) on their two pages, Bug 227305 is blocked by Bug
> 766073.

Alice0775 correctly created a link between these bugs, which is automatically reciprocated by bugzilla on both bugs (hence the same timestamp):

This bug 227305 "Depends on" ("is blocked by") bug 766073, in the sense that bug 766073 is a followup bug that points out potential improvement/problems in the current implementation of this bug (which, if verified, if you so wish, might logically imply that this feature, bug 227305, might still need improvement and in that sense feel free to think of it as "not fully fixed". However, in terms of our rules and procedures, Comment 143 still applies, per reasons in comment 149 and this comment).

> (I recall that this bug makes impossible to replace Outlook Express with TB for serious handling
> of email).

Everybody is free to have their own perspectives and opinions, but from my pov, with more than 6 years of experience in TB QA and UX, that statement does not apply at all to anything from comment 148 or bug 766073. Certainly we would all appreciate to have bug 634720 fixed so that drag & drop of *multiple* files becomes possible. To that end, I encourage interested users to vote for bug 634720 using the (_vote_) link in the bug header to put your interest on record, and I've tried my best to get things moving there, but we are still looking for a volunteer to fix it. As of now, there hasn't been much user interest in that bug (3 votes, 10 CCs, 1 duplicate, 13 comments). In the grand scheme of things, I see many other bugs that are more urgent/annoying or have more potential than bug 634720 & friends. More so as there's an easy workaround (Ctrl+S aka Save As...) which I'll file in my next comment.
Status: RESOLVED → VERIFIED
See Also: → 634720, 927694
Finally, everone who needs to save/export *multiple* messages into their file system as .eml files, TB provides a simple way of doing that:

- Select multiple messages (e.g. using Ctrl+click)
- Ctrl+S (or Save As... from context menu), choose target folder, DONE!

As simple as that, you'll then find all selected messages as individual .eml files in your target folder, including sender and timestamp information in the filename (somewhat ux-inconsistent with drag & drop, but that's another story again...)
Whiteboard: [read comment 141, 143 before commenting][delight] → [read comment 141, 143 before commenting][workaround for saving multiple messages (bug 634720): see comment 152][delight]
Whiteboard: [read comment 141, 143 before commenting][workaround for saving multiple messages (bug 634720): see comment 152][delight] → [read comment 141, 143 before commenting][workaround for saving multiple messages (bug 634720): see comment 153][delight]
Depends on: 939575
Unfortunately this bug is back. TB 52.7.0, macOS High Sierra 10.13.4. Neither dragging an email to the Desktop nor into a Finder window works anymore.
Flags: needinfo?(yuenhoe)
Addition: drag & drop of an attachment to Desktop and Finder window works.
Addition 2: this also does not work in a brand-new profile with no add-ons. Neither does it matter if the email is in the Inbox or in Sent.
(In reply to Lee Binder from comment #154)
> Unfortunately this bug is back. TB 52.7.0, macOS High Sierra 10.13.4.
> Neither dragging an email to the Desktop nor into a Finder window works
> anymore.

Please open a new bug with the details. Thank you!
Flags: needinfo?(yuenhoe)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: