Mike, this bug has no audience and you didn't ask anyone for review. In the meantime, review board has been phased out. Can you please attach the a simple text patch.

Also, I've tried to do the same thing in bug 1506488. That patch actually doesn't work, I don't know why. It's similar to yours. As you've seen, there's a flurry of activities in bug 393302, and we're actually removing code like

+	else
+		lpFiles = lpMessage->lpFiles;
+
+	hr = pNsMapi2->SendMailW(lhSession, lpMessage,
+		(short)lpMessage->nRecipCount, lpRecips,
+		(short)lpMessage->nFileCount, lpFiles,
+		flFlags, ulReserved);

in favour of copying the memory.

(In reply to Jorg K (GMT+1) from comment #3)

well - let me postpone updating this until the changes are settled in bug 393302 then...

This is updated after bug 393302. I saw that in the latter, the COM interface was changed easily, thus I decided to not create a "nsIMapi2", but simply extend existing nsIMapi.

After this patch, both LibreOffice and Explorer's "Send to -> mail recipient" start using this method in my testing on Windows 10.

Of course, the change has big parts copy-pasted. Yet, I didn't try to refactor the duplicated code. Unable to afford this at the moment, sorry.

Oh thank you! - of course you are right. Will update.

Patch updated after comment 8

Added HG header and commit message. Fixed white-space issues, overlong lines, one copy/paste error (in debug output).

More copy/paste errors.

... and one more :-(

Jorg: thank you so much! Sorry for all these errors. I admit that I didn't pay attention to comments/debug string :-( - but I hope that the executed code (apart from debug strings) should be OK? I tested it before sending, be assured!

More white-space tweaks.

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/aaf39a9bd368
Implement MAPISendMailW(). r=jorgk

I backported it to SeaMonkey 2.53 based on 56 and this seems to work fine there in Windows 8.1 and Server 2016. But under Windows 7 files names with unicode chars no longer result in a mail window shown. Previously they would show ?? for the unicode chars in the attachment.

Could someone test this with a Nighly Thunderbird under Windows 7. Regular file names still work so it is probably a unicode only regression if any. I am still on TB 60.5 and don't want to mess with the profile.

Thanks for testing!

There's actually no such thing as a "unicode character". Unicode is character encoding, so for example Ä or テ can be encoded in many different ways, UTF-8 being one of them.

So what you mean is that on a Windows system with a Western code page, like windows-1252, you used a file name which can't be encoded in that code page, right?

Unless I'm reading something incorrectly, MAPISendMailW is not available on Windows 7 (https://docs.microsoft.com/en-us/windows/desktop/api/mapi/nc-mapi-mapisendmailw). So this would be a regression of bug 393302, or maybe bug 1521007? Are you 100% sure that ever worked, see my comment in bug 393302 comment #69 where I tried with Japanese and Polish file names and no compose window came up. I'm also not sure where the ? replacement would have happened and how attaching a file could have worked, since it didn't exist with the ? name.

I know. Was just mean't as a simpification. Used the attached test file here.

It seems Virtualbox might be the culprit. If I try to use a unicode file from a virtual box shared folder in Win 7 it won't work. With a local file it seems to work but it displays the short Windows name for the attachment name. Both are ok under 8.1 and up. SeaMonkey has some different attachment handling which might be the cause here and it is also a downlevel Gecko 56 albeit heavily patched up. I wouldn't bother if the unicode case generally works in Win 7. Great work so far.

(In reply to Frank-Rainer Grahl (:frg) from comment #19)

I backported it to SeaMonkey 2.53 based on 56 and this seems to work fine there in Windows 8.1 and Server 2016. But under Windows 7 files names with unicode chars no longer result in a mail window shown. Previously they would show ?? for the unicode chars in the attachment.

It's very important to also state which program was used as calling application. E.g., last year I have changed LibreOffice to create a temporary file with ASCII-only names on send, and pass that filename to MAPI, to workaround that deficiency (in https://git.libreoffice.org/core/+/5566df47de17eca8c0a5b447bcb906051c869db6). So using LibreOffice, that would previously work (and now, too). Word also uses that technique. But Windows Explorer right-click menu launches some other application, which never could send files with names not representable in ACP ("Unicode names") previously to this patch. And Windows 7 doesn't have the W function in MAPI, as Jorg mentioned.

Please check the "Previously they would show ??" part, I guess it's some mistake.

Or an artefact of using the VM? Kai in bug 393302 comment #59 and cmt #64 claimed that he could send files with "unicode names" on his VM when I couldn't on "real" Windows 10.

(In reply to Jorg K (GMT+1) from comment #23)

I cannot say anything definitive regarding what could that be, except that Kai should have debugged that using VS debugger back then. I doubt, though, that UTF-8, even if actually sent by Explorer in the data, could be processed properly by TB back then, without what we implemented in bug 1521007, unless one used beta UTF-8 ACP in Windows 10. And I cannot see anything in our code that could describe VM differences.

Thank you guys for movement in this area. This looks like a reasonably standalone patch, would it be a candidate for backport to ESR60? Looks like bug 393302 is too.

Sure both (and more) are on my mental list. I plan to ship all MAPI fixes in TB 60.6.

(In reply to Frank-Rainer Grahl (:frg) from comment #19)

But under Windows 7 files names with unicode chars no longer result in a mail window shown.

(In reply to Mike Kaganski from comment #22)

And Windows 7 doesn't have the W function in MAPI, as Jorg mentioned.

MS says:
On Windows 8 and later: Call MAPISendMailW to send a message.
On Windows 7 and earlier: Use MAPISendMailHelper to send a message.
and:
MAPISendMailHelper function:
Takes Unicode message information and sends the message using MAPISendMailW or, if necessary, converts the message to ANSI and sends the message using MAPISendMail.
(https://docs.microsoft.com/de-de/windows/desktop/api/mapiunicodehelp/nf-mapiunicodehelp-mapisendmailhelper)

I think that first MAPISendMailHelper must be implemented so that unicode chars in the attachment works under Windows 7.

(In reply to bblack from comment #27)

I think that first MAPISendMailHelper must be implemented so that unicode chars in the attachment works under Windows 7.

No. MAPISendMailHelper is not something anyone needs to implement, because it's a function fully implemented in MS in Windows SDK (in MAPIUnicodeHelper.h). Its source code is open (in the said header), and is built-in into any application that decides to use this helper function.

Its deficiencies (related to handling of CP_UTF8) are raised in my request [1].

[1] https://developercommunity.visualstudio.com/content/problem/431508/mapisendmailhelper-implementation-is-inconsistent.html

TB 65 beta 4:
https://hg.mozilla.org/releases/comm-beta/rev/d6f7c0483b263905ed42ceebb5d61e0a5e5448a2