In the MailNews file menu there is a "Save As" submenu containing two items: File and Template. Both options work as expected for a single message, but when multiple messages are selected they remain enabled but simply do nothing. The simplest solution to this would be to just disable those two menu items when more then one message was selected. The better solution would be to get them to work with multiple messages as you would normally expect. IMHO, saving a whole group of messages to a single folder with one command would be one of the most useful applications of the Save as File menu item.

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

Platform / OS: All (see dup 58549). Confirming.

change qa contact

For reference, when saving multiple emails in NS4.x, it saves them all in one file. I used this a lot for saving formatted emails sent in via a form on my website (then going in and regexing out all the headers to get to the information). The only reason i bring this up is because the original description says it should save 'a whole group of messages to a single folder' (not file).. which would be a little painful (but of course not as painful as it not working at all).

For anyone who cares... the resulting behaviour of this bug happens to me (seemingly at random times) on Win95 with 2001071604 when trying to save file as from a web page, save picture as, save message as... when i have only *1* selected item. That result being of absolutely no dialogue. The only solution I have is to restart the browser. Something, somewhere, locks up.

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

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

reassigning to cavin.

Adding mozilla1.0 and 4xp keywords. This should seriously be fixed by 1.0. We shouldn't have menuitems that sometimes work and sometimes don't. Although I am not familiar with the mail backend, I believe this bug could be resolved with 4 lines of XUL and JS code by just disabling the menuitems when more than one message is selected. As I said before, this would not be ideal, but it's better than having a menuitem that doesn't do anything.

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

This patch disables menu items under "Save As" if the number of selected messages isn't 1.

Confirming Ryan O'Neill's statement that NS4.x would allow multiple messages to be selected and saved to a single file. We use this feature every day to collect form submissions from our website and import them into our database. This bug will prevent us from being able to use Mozilla (or, for that matter, NS6.x).

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

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

Saving all the messages into one file would not work as well if the messages contained HTML or graphics. For HTML messages it would be preferable to specify a folder and then save all selected messages to that folder (either using the subject as the filename or else just "message1.eml", "message2.eml", etc.

> Saving all the messages into one file would not work as well if the messages > contained HTML or graphics. For HTML messages it would be preferable to specify > a folder and then save all selected messages to that folder (either using the > subject as the filename or else just "message1.eml", "message2.eml", etc. > Uhm, good idea! Nonetheless I think it should be a further option: I beelive the traditional approach of storing everything in the same text file is still useful. No problem for binary attachements (html or graphics): there is the MIME format, some specific RFC about mail messages, and some encoding format (uuencode for example) describing how to put binary data into a plain mail message. I think it is worth to keep such a save modality, mainly becacause of compatibility with past and alike. For instance, it's not so convenient changing my backup scripts, nor doing a research on a directory rather than on a single mails-1999.txt file.

Would embedded images (etc.) still be displayed in the message body or would they be converted to attachments after saving/processing the messages? This is why the individual messages might be preferable ONLY for complex mail with HTML objects.

Whatever else happens, I hope that the behavior found in Netscape 4.x will be an option. In Netscape 4.x, the messages would all be saved in a single plain text file and one could then use uudecode, a text editor, or whatever to get things out of it. An option to save attachments separately using their native filenames would be nice too. So would the reporter's suggestion that each message be saved to a separate file in a folder. I guess I would consider those added features whereas the lack of the Netscape 4.x behavior is a bug. Should a new bug be filed for each of these options? If that is done, I hope the new bug numbers will be announced to this bug list.

I must agree regarding keeping the Netscape 4.x behavior at least as an option. As I stated before, we currently receive all of our online information requests to a single mail box. All the info requests are selected and then exported via "Save As" to a single text file each day. That file is then parsed and the data is imported directly into a database. Each message in a separate file would simply not work for us.

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

The keywords 'patch' and 'review' were added some minutes ago. The code attached to this bug is not really a patch. Instead of fixing the bug it disables menu items under "Save As" if more than one message is selected. This was meant as a "beautification" for 1.0 but didn't get checked in. It isn't relevant anymore. Removing keywords again.

Actually, Mozilla stores all those e-mails in mbox format. This should be how they are saved. pi

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

This parallels my recent comment at http://bugzilla.mozilla.org/show_bug.cgi?id=102960#c7 In fact, I'm going to cut-n-paste it here. Everything pertains except the "message.eml" file permissions, which are okay for messages which are already on the local box when saved using Alt-s. Here we go: I just checked in my Linux/mozilla 1.1b that I have on hand. I really want to chime in on this one. It's an aggrevating sucky bug. Maybe it's just because I don't get around very much, meaning basically that I haven't used Windows for any meaningful length of time since 3.1, but what the *hell* is an .eml message and what could possibly be interested in the apparent raw RFC822 format except sendmail & friends? I've only ever checked this before using local messages (as for bug #58140, and I'm heading there in a few minutes). Everything seems the same in news, except to pile insult on top of injury, the "message.eml" file is being written with mode 0700. There's no reason to be saving it with execute permission as well as in no useful format. Here are my specific suggestions: - Drop the option of even saving a whatever-the-hell-it's-supposed-to-be .eml format and include a proper "From " line at the top of the output. - If you even continue to offer .html and .txt formats, make them useful in some measure, the present formats seem only an exercise in doing *something* with the content. And (if you continue to offer the formats) make it so selecting the file type with the dialog automatically changes the extension and saved file type. The dialog currently seems to be only an exercise in drawing a dropdown selection box. It does nothing. - If you even suggest any filename at all (I opt for none) then don't use "message", but rather the subject line, or newsgroup name, or something halfway meaningful and useful. As it presently stands, the filename requires being selected and overwritten with something anyway. - Since you should already be adding a proper "From " line at the top of the raw output, saving multiple messages would result in proper mbox format message. Wouldn't that be useful? YES! - Oh, enable saving mutliple messages. - Maybe offer to overwrite a preexisting file as a secondary option, but have the primary action be to append the proper mbox format message to the existing file. Again, the purpose being to create useful output. The current setup is really utterly useless. Please, please try again. You had a perfectly good example in the 4.x series; the results here need not deviate in any respect from it.

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

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

I strongly agree that the Netscape 4.x behavior is a REQUIREMENT - multiple messages written to a single file. This has been the standard behavior for all e-mail clients I've used for 18 years, and I have many systems built around that standard. Mozilla mail is severely crippled for my purposes while this behavior is not present. Also, as noted in comment #22, Mozilla's "folders" are already stored as a single file containing multiple messages. If they can be (internally) stored that way, why can't they be written that way?

I just installed Mozilla 1.2.1 and was disappointed to see that this bug still isn't fixed. With Netscape 4.7x my colleagues and I used File | Save as a lot each January to store last year's mail as text and then delete the messages, getting rid of tons of attachments (which of course were saved as files on arrival). I hope we can have the old Netscape functionality soon. Saving formatting and images is less important.

nominating for fixing.

It is terrific that that this bug is being "nominating for fixing" -- it's only been since October 26, 2000 when it was first reported!

Mail triage team: nsbeta1-

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

My 2 pence, Saving mail is important, so is saving multiple mails, so is saving multiple attachments i.e. Select everything in the inbox, right click and say save all attachments, specify a directory and hey presto. Other options : Save All attachments and purge (i.e. delete the ones in mail to save space)

Malcolm Turnbull's idea (#33) is excellent. Removing attachments from a message (with or without saving them) would save a lot of space but still let the user keep the message. Should this be a new "bug" or thread in this forum? I would still need "Save as" on multiple files, though.

Yes, the featue in comment 33 is appealing, already two bugs dealing with the same issue exist, bug 2920 (yes, four years old) and bug 83040.

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

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

My vote if for adding the Netscape 4.x capability of copying multiple marked messages to a single file. Using the "Save As Alt+S" menu option which, when selected, generates a "Save Messages As" window for file name selection.

To Mr. Alfonso Martinez re #171407 -- if reporting bugs requires one to be a programmer on this project, then you're right. But in fact your remarks are a just an excuse for not handling a problem that was reported 3 years ago. I've done my share of programming and if I waited 3 years to fix a problem that has over 30 bug reports, I would have been out the door in a moment. So why don't you wise-guys either fix it or make the decision that it is a "feature" that is meant to stay and publish that decision for all of of to see. Until that time, this is a bug and it is fair game for us to report. My bet is that it will keep getting reported until it is fixed!

The question is not "what's the correct solution?" - most of us would accept Netscape 4.x behavior. The question is "Who do we have to kill to get someone assigned to do the (probably) couple of hours of work?". This bug is closing in on _three years_ old; I know it's not new and sexy, but it makes one wonder what other simple but necessary features are rotting by the side of the road.

I tried to write a patch, but it's very hard to me. :-( MsgSaveAsFile() in mailWindowOverlay.js calls SaveAsFile() only when one message is selected. SaveAsFile() in mailCommands.js passes the selected message's URI to nsMessenger::SaveAs(). This code should be changed so that nsMessenger::SaveAs() can handle multiple URIs.

This bug has been open for THREE YEARS!!!!! It prevents me (and I'm sure many others) from being able to leave Netscape 4.80 behind and use Mozilla (now at 1.4!). This is a very frustrating blocking bug for me. As others have said, this option should allow the saving of multiple selections into a single file. The order in which the articles are written to file should, imho, be the order in which they were selected.

Ian, I agree with you, but there is a workaround. Create a new folder with the name of the file you want, copy the messages there and get the file from (your mozilla dir)/Mail/Local Folders/(foldername). It's not easy, but it works. I need this feature, but on the other hand, I also need Junk filters, browser integration, better filters and better locale support. So, I had to give up using netscape mail a long time ago.

Hi Juliano, I am aware of this work around, but sometimes Mozilla is saving the parts in reverse order. On multipart binaries with hundreds of individual articles, sorting out the mess when uudeview can't decode properly is *extremely* time consuming.

ian: only Mozilla drivers are authorized to set (+) blocking flags. You can request (?) blocking status.

That is not a workaround. It cannot be considered a workaround as it does not reproduce the functionality that this bug has taken away -- all selected messages saved into one single text file. The worst part is that for the last three years, this bug has completely blocked our company from updating past Netware 4.x! It is a complete show-stopper. I find it unbelievable that three years have passed with absolutely no action taken on what should be a relatively easy fix. What is the hold up, here?

Whoops, that should've read: "all selected messages saved into one single text file, in the proper order."

I can think of two possibilities: a) it's not blocking anything "important" b) it's not a sexy bug It would be wonderful if, for 1.5 or 1,6, everything Netscapew 4.8 had that Mozilla doesn't was declared a blocking bug (i.e. either fix it or declare that functionality is not and will not be supported).

This is not only an annoying bug for several years, but a serious show stopper and is hindering a lot of people's work I know. Please fix ASAP or identify dependencies. Much Appreciated.

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

This bug is about saving emails to individual files in a single directory, with a default filename from headers. Read comment 0. The following format makes sure no emails would have the same filename. Re: Message Thread-2003-11-24-14:52.eml (or whatever format) (I don't know if : can be used in a filename in Windows, but it can be changed without too many problems). If you want to save multiple emails to a single file, see bug 102960. Updating summary to be more descriptive.

Given the clarification in comment 51, I don't believe this is 4xp after all.

It should be possible to define the files' names via placeholders, eg. "%DATE-%SUBJECT.%FORMAT"

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

(In reply to comment #51) There is no prior behaviour precient for SaveAs saving multiple emails to multiple files. This should simply be about restoring existing behaviour that has been broken. The behaviour of Netscape 4.x -- saving of multiple emails to a single file -- was broken in Netscape 6-7 and Mozilla. If these were to be two separate bugs then a separate bug report should have been opened nearly three years ago due to comment #4. But since there was prior behaviour that was broken, I don't understand why there would be two separate bug reports open on this. Saving to multiple files would be a new behaviour request, not a bug fix.

I think the disabled menu item is a really lousy way out of this problem. The Netscape 4.x behavior of saving multiple e-mails as a single text document was used by many people, including myself. It's unfortunate that this has now been open for YEARS and no resolution is anywhere in sight. This type of running-in-circles regarding bugs and behaviors that affect many people leads me to seriously question the Mozilla project.

I'd like it a LOT if it would be possible to save multiple selected files to a directory as ASCII-text files. Just better for export, archiving,... whatever. (using built in thunderbird from 1.7 b2) I mean - if it is possible to save one selected mail as whatever you want, why not do the same with multiple mails in multiple textfiles or one textfile or have TB at least do a batch saving of single mails to files.

hi, how's the status? i'm writing this with a new seamonkey nightly and it's still not there. what's the matter here? why is this open for 4 years???? it's a very basic and must-have feature! regards

Do as I have done. After several years of waiting for this fix I gave up and turned to MS Outlook. The Mozilla project is obviously ignoring the problem and the people it affects.

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

I implore you guys, please add this functionality, it seems rather trivial from a code perspective and obviously will make a lot of people very happy.

Is this ever going to get fixed? It's been a reported bug for OVER 7 YEARS!!

To the developers - Please make a statement about your position on this bug. Why have you left it in this state? Why has such a simple change been ignored when obviously so many people want it? Why was the patch offered from Koike Kazuhiko on 2002-03-17 never accepted, nor even commented on? Given that this simple bug/feature request is currently unassigned and open for 7 1/2 years, do you intend to do anything at all with it? If not, why not? I along with many other people would be very grateful if finally someone from the developers would take a position on this. We, the users, your customers and clientele, are very frustrated by this.

Comment on attachment 74594 [details] [diff] [review] patch This patch is obsolete, it just disables the menus, but that we already do. Ian: nobody has yet written a patch to do save the messages as individual files. Feel free to provide one, it would be nice to have.

Well, since it was me who filed this bug--7/2 years ago, wow!--I suppose I should volunteer to provide the patch. It can very likely be fixed entirely in chrome I would think, without any C++ hacking required, though I'd have to investigate further to find out for sure. To the end users waiting on this bug: if you don't see a path (or at least more comments) from me in the next few weeks, feel free to harass me about in until I do. Before I go too far though, let's resolve for sure what the desired behavior is: save multiple messages to multiple files (per the bug description), or to the same file (as some of the comments say was the NS4 behavior). Which do we want here?

I'd vote for multiple messages to one file, as I feel that the function serves mainly archiving purposes. If individual files are desired there is always the possibility of saving them individually.

I'd also vote for multiple messages to a single file. This is because (as I mentioned previously) there was never any feature in Netscape or Mozilla that saved multiple messages to multiple files. The feature that was broken saved multiple messages to a single file. I also agree with Peter's point that this would mainly be used for archiving purposes. Then again, how difficult would it be to give the end user a choice?

I believe the optimal solution would be to give the user a choice, with the default set to "many messages => one file". It may be different for e-mail, but the traditional case for newsgroups was saving all the parts of a binary into one file to be fed to a decoder.

I think the most important thing is to have the possibility to save multiple messages to a single file, this was, as Robert Huff said, the old default behaviour, which I too think is what most people are looking for. That said, I too think the optimal solution is to offer the user a choice. For example (as best I can do in text): ---------------- | <menu points> |------------------ | Save As -> | Single File | | <menu points> | Individual Files | | <menu .... > |------------------ --------------- Single file would have the user enter a file name. Individual files would be saved according to some schema. I can think again of several possibilities: <year.month.day-hour.minute.second-<first 30 characters of Subject> <year.month.day-hour.minute.second-<posters_name> <Subject-messageid> <Subject-year.month.day-hour.minute.second> <messageid-Posters Name> <year.month.day-hour.minute.second-messageid> I guess you get the idea - clearly multiple individual post saving is a little more complicated.

A choice between single and multiple files would be great but, if I had to choose, it would be to a single file which was the pre-Mozilla Netscape Navigator behaviour and most useful for searching. Does anyone know if this feature is functional in new versions of Navigator. Thanks in advance for any work on this bug. Cheers.

I don't really see why one would want all the mails in one file. How would you open this file? Eml files is one file per message. Even for archiving, having all the files in one directory, and I assume the file names would be the subjects (+some number perhaps) would work just fine. At least to me, just making it save as file (.eml) the way it does now, has very few drawbacks.

Meant to say "making it save as files".

> I don't really see why one would want all the mails in one file. How would you open this file? Well ... /if/ you save e-mail as one file, /and/ you save it in mbox format, then pretty much every MUA can read it. How often would that get used? No idea. I will guess not very often, and it's not likely to change which means the setting ought not to be a menu item or even a right click but should be set in Edit->Preferences or on whatever the "about:" page is that has all the variables.

.eml files open widely too, and in currently thunderbird can't open mbox files very easily - see bug 225896, bug 266175.

I agree wholeheartedly with Peter Rosen's position (#68): as I noted in 2003, I would (and I did) find saving multiple messages into one text file an easy archiving technique. As it stands now, I go into the profile "mail" folder and "zip" the folders containing messages to be archived before I delete those old messages. Of course, when I want to restore them, I have to "unzip" to a temporary mail folder where I started. This is not ideal for me and I don't like screwing around with those files. But I don't know of any other way to archive a bunch of messages. And the "mail" folder can't keep growing forever--it has to be pruned occasionally.

Same here. This is needed by a bunch of people. Period. Can we have a commitment on this one?

Yup, if I had to choose one, I'd choose 1 file with multiple messages saved in it. I used to use it to archive old messages as well, stuff I wouldn't ever need online again as part of my regular inbox, but stuff I may need to refer back to maybe once every few years. Saving as a txt means for maximum compatibility and easy searching. Ideally of course, saving both a single or multiple files would be good, but lets get ourselves back to where we were at least before we go for adding new stuff. Thank you so much Aaron for looking into this, sometimes the simplest, smallest bug or feature is worth a thousand times more than sexy, complex features.

For me one of the strongest arguments for this feature (or choice) is to avoid loss of email due to crashes. I get many thousands of messages a day, and sometimes I just don't have time to keep up with archiving them in an orderly way, especially since there is no automatic archiving function to do it for me. Several times now my Inbox has gotten so large that Thurderbird crashed, apparently from lack of sufficient memory, resulting in either a totally unrecoverable Inbox file, or a damaged file from which only some of the messages could be recovered. If I set it up for separate files, then the crashes might be avoided, and if one occurred, I would only lose the last message. I wonder how many others have had this problem.

There doesn't seem to be a consensus, but it seems to me that "multiple messages in one file" is in the majority. Does anyone know who the appropriate module owner is (that could perhaps make the final decision on this)? Speaking of modules, we are talking about Thunderbird now, right?

jon.roland@the-spa.com you managed to spam the wrong bug, the bug you want to *NOT* SPAM is bug 58140. Please *READ* bugs before you *CONSIDER* spamming them. and then do us the favor of not commenting.

I object to timeless characterizing my post as spamming. I was providing an additional justification for giving this bug a higher priority. I favor having a choice of single file or multiple files, but would probably choose multiple files for most of my accounts that get a lot of email. For the low-volume accounts, I would probably use single-file. If you check the archives you will find I am one of the early participants on this bug.

(In reply to comment #81) > Speaking of modules, we are talking about Thunderbird now, right? > Yes, Aaron, we are talking about Thunderbird.

I'm one of the thunderbird module peers. I think saving as individual files would be most user friendly, for the reasons I mentioned in comment 76. It's also what this bug asks for. If normal people can't open the files you save, what good is it? And it's also probably easier to implement;)

Like the smartsave add-on? https://addons.mozilla.org/en-US/thunderbird/addon/2887 I for one would love to have an export function which saves all selected messages into ONE file ( 2008Feb.html ) and maybe even configurable enough to f.e. ignore parts of the header ( like unique ID, routing ) and have a clear and easily searchable separator ( Say "######## NEW MAIL ########" ). How attachments are saved is an other issue, maybe we could substitute the reference inside the mail with something like "Attachment Example.jpg is saved as 2008Feb_html_Attachment_01.Example.jpg" and than save the attachment to the same directory where the ONE file (2008Feb.html) was saved. Just an idea...

I can see how this bug description can be interpreted in two ways: save multiple messages as: 1) Individual MESSAGE files or 2) Individual CONTAINER files I opt for the second, with one file for all the messages I've selected. I can already accomplish the first using T. Gitlin's old Mail-to-Text utility, but don't have a way to save multiple messages to a single file. Although a way to choose either option is an ideal, I'm hoping to have the old Netscape 4 functionality back again. I wish I had the ability to contribute the programming, but can only thank those who do.

I vote for the saving of all selected messages into one file as being the top priority. This is how it was done in Netscape, and this is the functionality I am looking for. I guess for those who want to save messages into a directory, the messages could be exported into a directory in the maildir format. Maybe thunderbird should be saving messages that way by default anyway, to prevent these massive mbox files building up and the crashing problems that some people have been having.

(In reply to comment #83) > I object to timeless characterizing my post as spamming. I was providing an Just a note in case it wasn't clear, this bug is about File | Save As | File functionality, not how thunderbird stores mails internally. (For internally storing mails as individual files see maildir - bug 58308.)

(In reply to comment #67) > To the end users waiting on this bug: if you don't see a path (or at least more > comments) from me in the next few weeks, feel free to harass me about in until > I do. Ping! :)

Aaron: any progress?

Not really. In a moment of questionable sanity, I signed on to a graduate school program in mathematics while keeping my full-time software engineering job. (Not a good idea for anybody who wants to have an actual life or any hobbies outside of work and school.) Sorry about that. I have put this on my calendar to get finished one way or the other right after midterms.

Aaron, will you still work on this? Which would be great. But if you don't, please let us know so that we can correct assignment. I almost fell off my chair seeing this bug in action in the year 2009. Unfortunately, I wouldn't know how to fix it. For someone who knows, I guess it's just adding the loop for all selected messages - since all the functionality for saving a /single/ msg as .eml is already there. As per Magnus comment #85, a basic patch should just save selected msgs as individial .eml files. Saving them all into a single mbox file is a different bug that should be addressed thereafter.

Put up a dir chooser and save the in the chosen dir messages using the "subject - from - isodate.eml" scheme. I choose to go for a longer name to avoid naming collisions for the filenames. If we want this for tb3 it has one string, which we can temporarily exclude (would make the dir picker dialog have an empty title which is not a huge problem as it's pretty clear what to do).

(In reply to comment #96) > If we want this for tb3 it has one string, which we can temporarily exclude > (would make the dir picker dialog have an empty title which is not a huge > problem as it's pretty clear what to do). Whilst I'm sure this would be nice for TB 3 and the risk is fairly low, I definitely wouldn't take a string for it. I'm also in two minds (but verging towards not) about taking the fix as we're now need to be locking down and not having new features implemented. As TB 3.next is likely to be a short cycle, this would be a great thing to add for that.

Mark, I understand your caution, but I think you can tell from the number of messages in this thread, and from the number of times this bug is reported as a new bug (and then marked as a dup of this bug), there are a lot of people who will be made so happy when this gets fixed. Personally, I'm pretty sure this will be the most used new feature for me the moment it gets implemented. So if there's any way to get this implemented in 3.0, I would be super grateful. Sometimes the smallest fix can add so much joy.

We have lived forever with so many bugs, and TB3 will probably ship with a lot of bugs and a painful lot of things to be desired, and we're skipping great features because they don't have a caption on a folder picker!?!? FTR, I am 100% positive that people will complain about the lack of this basic feature more than they'll miss that little caption on a dialogue that is really self-explaining, as Magnus rightly points out. I've said this before: 30 votes plus lots of duplicates on bmo is likely the equivalent of tens of thousands of users out there. But then, why give users what they want? Sorry but I don't really trust that 3.1x will actually be released soon. And what is soon anyway, after I don't know how many years of waiting for the thing to improve?

I'd like to point out a few things: - We have less than 2 weeks until the final code freeze for Thunderbird 3. - We need Thunderbird 3 to be stable and well tested otherwise users will complain more (e.g. especially if it crashes a lot). - My decision was not final, just trying to set likely expectations.

Thanks to this bug, I've discovered SmartSave (https://bugzilla.mozilla.org/show_bug.cgi?id=58140#c86). Maybe you want to integrate it straight in TB.

Comment on attachment 406925 [details] [diff] [review] proposed fix In general, this looks good. The isodate is a bit odd, e.g., - [Bug 490548] A MozMill test - bugzilla-daemon@mozilla.org - 2009-10-20T06 55 47.eml The TO between the date and time is odd, but that's probably a question for Bryan. This patch is relatively safe, in that it's not going to break any existing functionality. I'm not sure we should rush it into 3.0, but I don't feel strongly either way.

Yeah the colons for times get sanitized for windows :/ I guess we could just do yyyy-mm-dd hhmmss instead. Many date formats have '/' which is a reason i went for iso date format. Hm, perhaps the SaveMessages string should be "Choose Folder"?

The TO does seem a bit odd (In reply to comment #103) > Yeah the colons for times get sanitized for windows :/ > I guess we could just do yyyy-mm-dd hhmmss instead. Many date formats have '/' > which is a reason i went for iso date format. I'd be fine with just using the yyyy-mm-dd hhmms format instead. > Hm, perhaps the SaveMessages string should be "Choose Folder"? Yeah, that makes sense to me.

Comment on attachment 406925 [details] [diff] [review] proposed fix Oh, so with the comments in Comment #104 addressed this can get a ui-r+

Patch for branch without the string.

With string.

Oh, i skipped the seconds from the date.

(In reply to comment #108) > Oh, i skipped the seconds from the date. I'd skip them unless you think they are needed

Comment on attachment 407569 [details] [diff] [review] proposed fix, v2 (for branch) This patch is effectively a new feature, there are no unit tests with it, and we have about a week and a half to code freeze. Whilst it would be nice to have fixed, we have to balance out getting Thunderbird 3 stable for its release. As it stands, this patch also isn't correct and needs more testing. The Save As item in the context menu is incorrectly shown. Currently it is shown any time there is a message folder present in the view. This isn't correct, we hide other context menu options when right-clicking on videos, images etc, and we should be doing the same here. The additional result is that when showing the global search results as a list the save as option is no longer available.

I'd also ask if it has been tested what happens if someone sends an email with the same message in the same subject in the same minute? Do we end up with one email or multiple as we should do. Whilst I suspect this doesn't happen often, see the three emails from Mike in this newsgroup thread in the same minute (at 4:52pm): http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/2fcd83608b62d5ce#

If the filenames would get identical the second name will get automatically transformed from foo.eml to foo-2.eml (or foo-3.eml) and so forth. (Yes, it's tested.)

(In reply to comment #110) > should be doing the same here. The additional result is that when showing the > global search results as a list the save as option is no longer available. Where do you see this? I don't see a context menu anywhere for gloda results.

Don't show save as context for links, media etc. (The msgFolder check is really an isDummy check, maybe we should rename it.)

(In reply to comment #113) > (In reply to comment #110) > > should be doing the same here. The additional result is that when showing the > > global search results as a list the save as option is no longer available. > > Where do you see this? I don't see a context menu anywhere for gloda results. Once you've done a global search, either select "Open as list" or click one of the email subjects, you'll then get a thread pane + message preview window where the results are displayed and you get the context menu.

Comment on attachment 407824 [details] [diff] [review] proposed fix, v3 Sorry for the delay in getting back to this. >diff --git a/mail/base/content/mail3PaneWindowCommands.js b/mail/base/content/mail3PaneWindowCommands.js > case "cmd_saveAsFile": >+ return GetNumSelectedMessages() > 0; This bit has bitrotted, but is an easy fix. >- this.setSingleSelection("mailContext-saveAs"); >+ this.showItem("mailContext-saveAs", msgFolder && !this.onCanvas && >+ !this.onLink && !this.onImage && >+ !this.onPlayableMedia); I've had a look at this, you are indeed right that we shouldn't be using msgFolder - the effect is even worse in the global search results list as we don't ever get a message folder there (because the search results are cross folder, I think saved searches would suffer the same result as well). I've had a play around and I think this is the right combination of checks: this.showItem("mailContext-saveAs", this.numSelectedMessages > 0 && !this.hideMailItems && !gMessageDisplay.isDummy && !this.onPlayableMedia); r=Standard8 with that fixed.

changeset: 4462:e877d6305e28 http://hg.mozilla.org/comm-central/rev/e877d6305e28 ->FIXED for trunk: thunderbird 3.1

Thank you, Thank you, Thank you, Thank you, Thank you, Thank you! This will be the absolutely best new feature of the new release.

Could you please refrain from "stealing" bugs out of the SeaMonkey/MailNews:Core component into Thunderbird? Thank you very much. :-|

Be sure to look at show_activity.cgi before you accuse us of stealing your bugs, so you can avoid the embarrassment of doing so in a bug where the reporter stole it because after seven years he had changed products and decided that nobody else was going to fix it so he would have to fix it himself.

(In reply to comment #120) > where the reporter stole it I'm very well aware of this. > it because after seven years he had changed products and decided > that nobody else was going to fix it so he would have to fix it himself. That's no excuse. And actually, I'm a bit amused that "you" felt hurt, given that "you" weren't even mentioned. ;-)

Where is matching SeaMonkey bug, so I could follow progress again?

Reproduce with SeaMonkey/20100130-trunk/WinXP. Reopen or File for New bug?

(In reply to comment #123) > Reproduce with SeaMonkey/20100130-trunk/WinXP. > > Reopen or File for New bug? Yes file a new bug about hooking up the front-end code for seamonkey.