use unique file name with full details when saving a *single* message as .eml file (as we do for multiple messages)
Categories
(Thunderbird :: Preferences, enhancement)
Tracking
(thunderbird_esr91+ verified, thunderbird92 affected)
People
(Reporter: gerardr, Assigned: gerardr)
References
(Regressed 1 open bug)
Details
(Keywords: dupeme)
Attachments
(4 files)
1.37 KB,
patch
|
Details | Diff | Splinter Review | |
1.18 KB,
patch
|
Details | Diff | Splinter Review | |
646 bytes,
text/plain
|
Details | |
48 bytes,
text/x-phabricator-request
|
wsmwk
:
approval-comm-esr91+
|
Details | Review |
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•3 years ago
|
||
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.
Assignee | ||
Comment 2•3 years ago
|
||
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.
Assignee | ||
Comment 3•3 years ago
|
||
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.
Assignee | ||
Comment 4•3 years ago
|
||
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•3 years ago
|
||
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
Assignee | ||
Comment 6•3 years ago
|
||
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.
Assignee | ||
Comment 7•3 years ago
|
||
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.
Assignee | ||
Comment 8•3 years ago
|
||
Here's the revised SaveAsFile subroutine so you can view the result of the patch.
Assignee | ||
Comment 9•3 years ago
|
||
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/2f2336f0879e
Change SaveAsFile to always use the long filename format. r=mkmelin
Updated•3 years ago
|
Comment 11•3 years ago
|
||
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•3 years ago
|
||
Comment on attachment 9236062 [details]
WIP: Bug 1722223 - Change SaveAsFile to always use the long filename format.
[Triage Comment]
Approved for esr91
Comment 13•3 years ago
|
||
bugherder uplift |
Thunderbird 91.2.0:
https://hg.mozilla.org/releases/comm-esr91/rev/2f6673d04025
Comment 14•3 years ago
|
||
Filename has Subject, Sender and Date in my test of 91.2 on Windows 10.
Comment 15•2 years ago
|
||
@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)
Description
•