1140323 - threadPane._onDragStart/ThreadPaneOnDragStart() should use same logic or code as SaveAsFile() for ".eml" file name generation

Status: ASSIGNED

(MailNews Core :: Backend, defect)

Description

[WADA:World Anti-bad-Duping Agency]

ThreadPaneOnDragStart() should use same logic or code as SaveAsFile() for ".eml"  file name generation.

http://mxr.mozilla.org/comm-central/source/mail/base/content/mailCommands.js#342
342 function SaveAsFile(uris)
349     if (msgHdr.flags & Components.interfaces.nsMsgMessageFlags.HasRe)
350       name = (name) ? "Re: " + name : "Re: ";
352     let filename = GenerateValidFilename(name, ".eml");

http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#1379
1379 function ThreadPaneOnDragStart(aEvent) {
1421     if (!subject) {
1422       uniqueFileName = noSubjectString;
1423     } else {
1424       uniqueFileName = (subject.length <= maxUncutNameLength) ?
1425                        subject : subject.substr(0, maxCutNameLength) + longSubjectTruncator;
1426     }
1427     uniqueFileName = suggestUniqueFileName(uniqueFileName, ".eml", fileNames);

Due to above difference, when Subject has Re:, SaveAs generates "Re subject_text.eml", but Drag&Drop generares "subject_text.eml".
Is it intentional or by design?

Comment 1

[Magnus Melin [:mkmelin]]

https://searchfox.org/comm-central/rev/53f8d49164c269f0936f7415c969320becbb0c25/mail/base/content/about3Pane.js#5379
https://searchfox.org/comm-central/rev/53f8d49164c269f0936f7415c969320becbb0c25/mail/base/content/mailCommands.js#503

Comment 2

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 1140323 - Unify message filename generation in MailUtils. r=#thunderbird-reviewers

Move sanitisation, shortening and uniqueness of message filenames into a new
nsIMsgFilenameUtils service that accounts for the actual destination path, and
drive batch saving of messages from the front end, so filenames are resolved
against the folder the user picks. The protocols which write the file
themselves (IMAP, EWS and NNTP) now write into the existing file instead of
replacing it, so that the file the front end creates to reserve a name stays
reserved until the save has finished.

The sanitising rules are portable, but the amount of room a name has is not:
the budget is PATH_MAX bytes of the native path on POSIX and MAX_PATH UTF-16
units on Windows, and neither the limits nor the native path (nsIFile's
nativePath() is [notxpcom]) are reachable from JS. Keeping the logic in C++
behind an XPCOM interface leaves one implementation shared by the front end and
by C++ callers, instead of having each of them approximate the platform's
limits.

Further code which turns untrusted text into an on-disk name can be
consolidated here later. NS_MsgHashIfNecessary() in nsMsgUtils.cpp, used for
folder, mbox and offline store names, truncates and hashes above a fixed 55
characters, without checking for reserved device names or counting bytes.

Comment 3

[Hartmut Welpmann [:welpy-cw]]

Attachment: WIP: Bug 1140323 - Improve tests for saving EML messages. r=#thunderbird-reviewers

Rewrite test_save_eml_as_file1 and test_save_eml_as_file2 to properly
test saving .eml files opened from disk and from attachments:

• Use MockFilePicker.setFiles() to provide an actual destination file
  so the save proceeds through the full code path.
• Wait for the async save to complete via TestUtils.waitForCondition.
• Compare the saved file content against the original source to verify
  round-trip fidelity, normalizing line endings.

Move MockFilePicker init into add_setup with a single cleanup function
to reduce per-test boilerplate.

Comment 4

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 1140323 - Route standalone EML saves through the mailbox backend. r=#thunderbird-reviewers

This removes the frontend workaround in mailCommands.js that used top.saveURL
for standalone .eml files, properly routing the operation through messenger.saveAs
and the C++ backend.

Key backend changes in nsMailboxService.cpp:

• Moved the file: to mailbox: URI conversion logic from FetchMessage down
  into PrepareMessageUrl. This allows file: URIs to be properly processed
  by all mailbox actions, most notably SaveMessageToDisk.
• Fixed a URI construction bug where number=0 was appended with an &
  without checking if a ? query string already existed.
• Forced addDummyEnvelope to true for file: URIs in SaveMessageToDisk
  to prevent the mailbox protocol from swallowing the first header line
  (since .eml files lack the mbox "From " separator).

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/72f24353e83a
Route standalone EML saves through the mailbox backend. r=mkmelin

Comment 6

[Hartmut Welpmann [:welpy-cw]]

Attachment: WIP: Bug 1140323 - Preserve generated message filenames when saving. r=#thunderbird-reviewers

Limit generated Save As filenames to 255 UTF-8 bytes so collision checks
use their final names. Replace AdjustFileIfNameTooLong with a platform
path-length check; backend shortening could turn distinct names into the
same destination.

Prompt for a new file or folder when a selected path is too long. Check
all batch destinations before starting any saves, validate paths chosen
after an overwrite prompt, and cover both retry flows in browser tests.

Comment 7

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 1140323 - Migrate message file strings to Fluent. r=#thunderbird-reviewers

Migrate nsMessenger prompts and file picker strings, message drag fallback
filenames, and the open-message file picker from messenger.properties.
Reuse existing attachment messages and format C++ strings with
LocalizeMessage.

Add the locale migration recipe and focused filename and picker tests.
The path length strings are not yet in the localization source, so their
existing English values are seeded by the recipe.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/1277e5088c80
Migrate message file strings to Fluent. r=mkmelin,tobyp,dandarnell