1722223 - use unique file name with full details when saving a *single* message as .eml file (as we do for multiple messages)

Status: VERIFIED FIXED

(Thunderbird :: Preferences, enhancement)

Description

[Gerard A. Robinson]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Saved a single email message, and got only the subject contents as the filename. Then saved 2 email messages in one operation, and got a longer filename including the sender and a timestamp.

Actual results:

See "What did you do" above.

Expected results:

Hoped for results are that I could somehow select the longer filename format as the default for all message saves, regardless of the number of messages in the save operation.

Comment 1

[Thomas D. (:thomas8)]

Thanks Gerard, that would appear useful indeed.
Can't find an existing bug for this, maybe there's one, but it's definitely something which I've often found surprising.
I'd also want this as a pref, not as a default - when John doe saves an occasional message, maybe the subject-only filename might be enough, but for any more frequent or enterprise users, they'd want the full details in the file name.

An annoying problem about the subject-only file name when saving a single message is that it will not be unique, so if at a later time I want to save another message from same thread, I can easily end up overwriting the first.

Comment 2

[Gerard A. Robinson]

Thanks! Maybe it can be done in phases. Just like 'mail.save_msg_filename_underscores_for_space' is a preference only available (that I can tell) in 'about:config', perhaps (for example) 'mail.save_msg_filename_always_long_unique' could get created and used first, and then later develop a UI for setting it somewhere within the Preferences dialog.

Comment 3

[Gerard A. Robinson]

Attachment: A diff generated patch for adding just the preference and then using it.

I created this bug in part because I couldn't find where the filename was being generated. I realized (with a little delay), when I wrote about the 'mail.save_msg_filename_underscores_for_space' preference, that I could use that to find the filename generation. Thus I made these changes, and now have to try to drag through how to get Thunderbird built in order to test it.

Comment 4

[Gerard A. Robinson]

Instead of a full build, I had the bright idea (since it was just javascript), that I'd look in the distributed run-time files and found omni.ja. This I 'unzip'd (I'm running Linux), added the one preference line and changed the first line in 'SaveAsFile', then ran 'zip -fr ../omni.ja *' to "freshen" omni.ja with the two changed files. Started up Thunderbird, went to Preferences>General>Config Editor, searched for, found and toggled the new preference, and tested some single message saves. It is working for me.

HOWEVER, the 'save file' dialog box no longer presents a single file name to potentially be edited when the always unique preference is set. This may annoy some users. So, my proposed fix is probably too simplistic for general distribution. I can, though, automate the update of my local omni.ja so I get what I want in the meantime, thanks.

Comment 5

[Magnus Melin [:mkmelin]]

I think we don't need the pref, we could just always use the same format. Can you submit a patch for that? See https://developer.thunderbird.net/thunderbird-development/fixing-a-bug

Comment 6

[Gerard A. Robinson]

OK, thanks. Here's the patch to make the filename always long (without preference), when saving just one message:
`
--- chrome/messenger/content/messenger/mailCommands.js.orig 2010-01-01 00:00:00.000000000 -0500
+++ chrome/messenger/content/messenger/mailCommands.js 2021-08-12 11:04:21.202319731 -0400
@@ -463,12 +463,10 @@
if (uris.length == 1) {
let uri = uris[0];
let msgHdr = messenger.messageServiceFromURI(uri).messageURIToMsgHdr(uri);

• let name = msgHdr.mime2DecodedSubject;

• if (msgHdr.flags & Ci.nsMsgMessageFlags.HasRe) {

•  name = name ? "Re: " + name : "Re: ";
  

• }

• let filename = GenerateValidFilename(name, ".eml");

• let nameBase = GenerateFilenameFromMsgHdr(msgHdr);
• let filename = GenerateValidFilename(nameBase, ".eml");
• messenger.saveAs(uri, true, null, filename);
  } else {
  let filenames = [];
  `

I've done a preliminary test of it in Thunderbird 91.0 (the line numbers above relate to the v91.0 version of mailCommands.js).

I'll work through the formal patch submission process.

Comment 7

[Gerard A. Robinson]

Attachment: tb-filename-always-unique.patch

I prefer this patch better, as I prefer not to duplicate code within a subroutine unless I have to. I'll be attaching the new subroutine to this request as well, and once I get through downloading the code, and learning about moz-phab, I'll make a formal submission.

Comment 8

[Gerard A. Robinson]

Attachment: tb-saveAsFile-new.js

Here's the revised SaveAsFile subroutine so you can view the result of the patch.

Comment 9

[Gerard A. Robinson]

Attachment: WIP: Bug 1722223 - Change SaveAsFile to always use the long filename format.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/2f2336f0879e
Change SaveAsFile to always use the long filename format. r=mkmelin

Comment 11

[Rob Lemley [:rjl]]

Comment on attachment 9236062 [details]
WIP: Bug 1722223 - Change SaveAsFile to always use the long filename format.

[Approval Request Comment]
Been on beta since 93.

Comment 12

[Wayne Mery (:wsmwk)]

Comment on attachment 9236062 [details]
WIP: Bug 1722223 - Change SaveAsFile to always use the long filename format.

[Triage Comment]
Approved for esr91

Comment 13

[Rob Lemley [:rjl]]

Thunderbird 91.2.0:
https://hg.mozilla.org/releases/comm-esr91/rev/2f6673d04025

Comment 14

[WaltS48 [:walts48]]

Filename has Subject, Sender and Date in my test of 91.2 on Windows 10.

Comment 15

[Peter]

@Alfred This is certainly not a "regression" as this new behavior is obviously intentional (per the history on this "bug" filing). However it's definitely not a welcome change for everyone, and yes at least a preference item should have been included to allow reversion to the previous file naming behavior. I've also commented in bug 1736194. (Peter)