Adding custom headers to an email or a newsgroup article through mail.compose.other.header is broken.

STR:

• Add an header to the pref: mail.compose.other.header e.g. X-Header1
• Open a new compose window
• add an additional header through clicking onto 》next to the BCC button.
• select X-Header1
• add some text eg: foo bar
• send mail/article

Instead of the new header X-Header, a header...
Null: "foo bar"
... is added.

http://kb.mozillazine.org/Custom_headers

Confirming for 78.1.1 (64-bit). Works in 68.11.0 (32-Bit).
Alice, could you find the regression window?

(In reply to Alfred Peters from comment #0)

Adding custom headers to an email or a newsgroup article through mail.compose.other.header is broken.

Thank you Alfred! Good find!

This should be from the pills re-design.

#2 Regression window (Toaddrlabel: "foo bar" instead X-Header1: foo bar):
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=c10cbc3c87fb2004d7ca3ae2525cf4be48bf377c&tochange=019eaf0f9cf72621a436ce06b2607bc5a3532fae
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d6d7d85a1b56cd92f74447d28381423d6980cd92&tochange=192e0e33eb597e8d923eb89f6d49bf42654e9d11

#2 Regression window (Null: "foo bar" instead Toaddrlabel: "foo bar"):
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=2dff5349a09ff6b7ad3c5febf222bf8e9b7eb414&tochange=75ad64af9fe2e20cffc78ad78a6a42291fc115ec
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6f6e201853c8f5053d6f8837acf89e76f5a334c5&tochange=6f6e201853c8f5053d6f8837acf89e76f5a334c5

(In reply to Magnus Melin [:mkmelin] from comment #4)

This should be from the pills re-design.

Indeed. Bug 440377 and bug 1603166.

Thanks Alice!

Ping, can you work on this. Code might be around https://searchfox.org/comm-central/source/mail/components/compose/content/addressingWidgetOverlay.js

This patch sets aria-labelledby to the input inside input-container, then when a pill is created, aria-labelledby will be set to pill.emailInput.
https://searchfox.org/comm-central/source/mail/base/content/mailWidgets.js#2337-2339
https://searchfox.org/comm-central/source/mail/components/compose/content/addressingWidgetOverlay.js#81-83

I think there is a separate issue, if I click the Send button directly without blurring the custom header input first, the header won't be included. Same for other address inputs.

There is another problem: if X-Header1 has value a; b; c or a, b, c, according to https://searchfox.org/comm-central/source/mail/components/compose/content/addressingWidgetOverlay.js#81-83, only the last pill will be used, so X-Header1: c will be included in the sent message. For other address pills, we use , to concatenate them, but in the case of custom headers, we can't be sure user typed , or ;. I think we should change the custom header input to be a plain input without pills, like the Subject input.

This patch disables pill in the custom header input. This is better than the patch in comment 9, because it also fixes comment 10.

(In reply to Ping Chen (:rnons) from comment #9)

I think there is a separate issue, if I click the Send button directly without blurring the custom header input first, the header won't be included. Same for other address inputs.

I guess that also causes bug 1658509?

(In reply to Ping Chen (:rnons) from comment #11)

Created attachment 9170580 [details] [diff] [review]
1658890-no-pill.patch

This patch disables pill in the custom header input. This is better than the patch in comment 9, because it also fixes comment 10.

Yes, it works - so far.

An important function of these additional headers is to set the 'Supersedes' header in newsgroups. This header is used to replace a newsgroup article with a revised version.
To do this, the Message-ID of the article to be replaced must be entered in the header:

Supersedes: <r17ebb.68g.1@gammasigma.xy>

But if I enter the Message-ID, TB cuts off the angle brackets.
This can be seen already in the Pill.

(In reply to Ping Chen (:rnons) from comment #11)

Created attachment 9170580 [details] [diff] [review]
1658890-no-pill.patch

I noticed something else: 8-bit characters are not handled correctly.

X-Header1: Test äöü
becomes:
X-Header1: =?UTF-8?B?VGVzdCDvv73vv73vv70=?=
but that decodes to:
X-Header1: Test
(= <u+FFFD>, the 'Replacement Character')

X-Header2: Test 😃
becomes:
X-Header2: =?UTF-8?Q?Test_=3d=03?=
which decodes to:
X-Header2: Test =

But this might be a completely different bug...

{Just a warning: If you wanna test Comment 13 or Comment 14 - Current Trunk builds do crash on viewing new news articles due Bug 1657493.
But you should be able to test it by email as well.}

(In reply to Alfred Peters from comment #14)

I noticed something else: 8-bit characters are not handled correctly.
But this might be a completely different bug...

Right, Gene and I would have fixed that in bug 1658361. Get a TB 78.2 pre-build an try it there:
https://mail.mozilla.org/pipermail/tb-planning/2020-August/007760.html

(In reply to Jorg K (CEST = GMT+2) from comment #16)

Right, Gene and I would have fixed that in bug 1658361. Get a TB 78.2 pre-build an try it there:

I tested it with current trunk. That build should already have the Bug 1658361 patch.
But TB 78.2 pre-build hasn't the patch of this bug.

Apologies, Alfred, the fix was related to addressing headers. Can your issue from comment #14 be reproduced with a normal mail message?
I created a message with

Subject: Test =?UTF-8?B?w6TDtsO8?=
X-Header-1: =?UTF-8?B?w6TDtsO8?=

and that's correctly displayed correctly as äöü. =?UTF-8?B?VGVzdCDvv73vv73vv70=?= appears to be wrong to start with.

(In reply to Jorg K (CEST = GMT+2) from comment #18)

Apologies, Alfred, the fix was related to addressing headers. Can your issue from comment #14 be reproduced with a normal mail message?

Yes.

I created a message with

Subject: Test =?UTF-8?B?w6TDtsO8?=
X-Header-1: =?UTF-8?B?w6TDtsO8?=

and that's correctly displayed correctly as äöü.

"create a message"? This bug isn't about saved messages.

Compose just a new mail and send it. See STR.

=?UTF-8?B?VGVzdCDvv73vv73vv70=?= appears to be wrong to start with.

That is what TB made of it.

But again: The encoding problem is not that urgent.
It would be nice, if Comment 13 could be fixed in this bug (Ping Chen?).
And then I'll open a new bug for Comment 14.

(In reply to Alfred Peters from comment #19)

"create a message"? This bug isn't about saved messages.
Compose just a new mail and send it. See STR.

OK, got it, sorry. If per the STR in comment #0 you create non-ASCII-content in the custom header, then it ends up badly in the message. Understood. It's just a bit confusing that comment #0 says Null: "foo bar" created, when in comment #14 you show X-Header-1. Anyway, once the custom headers are restored, we should test them with non-ASCII content.

(In reply to Jorg K (CEST = GMT+2) from comment #20)

Understood. It's just a bit confusing that comment #0 says Null: "foo bar" created, when in comment #14 you show X-Header-1. Anyway, once the custom headers are restored, we should test them with non-ASCII content.

That's with the patch of Comment 11. It works fine - just with the nits of Comment 13 and Comment 14.

Well, I don't consider mis-encoding a "nit". Mojibake is just not tolerable anywhere. So if we restore the function, it needs to restored to its previous glory.

Sorry for being late, I misread comment 13 and thought comment 14 was a separate issue. This patch

• fixes the disablePill handling, the patch in comment 11 was somehow messed up, this patch prevents custom header value becoming pills. This should fix comment 13.
• uses setHeader instead of setRawHeader. From reading the function name, I thought setRawHeader will set the verbatim header name/value, but it turns out to be the other way around. https://searchfox.org/comm-central/source/mailnews/mime/src/MimeJSComponents.jsm#213-214. This should fix comment 14.

I did some testing, message-id is unchanged. Test äöü becomes =?UTF-8?B?VGVzdCDDpMO2w7w=?= and Test 😃 becomes =?UTF-8?B?VGVzdCDwn5iD?=. Please see if it works for you now.

(In reply to Magnus Melin [:mkmelin] from comment #24)

I don't seem to get any new headers showing up

I've added this to user.js, and id5 is correct:

user_pref("mail.identity.id5.headers", "archive, supercedes");
user_pref("mail.identity.id5.headers", "archive");
user_pref("mail.identity.id5.header.archive", "X-No-Archive: yes");
user_pref("mail.identity.id5.header.supercedes", "Supercedes:
<1234@example.com>");

I will take a look next week. But even if no headers show up, it's a separate issue. This bug is about mail.compose.other.header and typing the header content manually in the compose window. As I understand, mail.identity.id5.headers are default custom headers appended to every sent message.

(In reply to Ping Chen (:rnons) from comment #23)

Created attachment 9171319 [details] [diff] [review]
1658890-no-pill.patch

I did some testing, message-id is unchanged. Test äöü becomes =?UTF-8?B?VGVzdCDDpMO2w7w=?= and Test 😃 becomes =?UTF-8?B?VGVzdCDwn5iD?=. Please see if it works for you now.

Yes, works here also.

(In reply to Ping Chen (:rnons) from comment #25)

(In reply to Magnus Melin [:mkmelin] from comment #24)

I don't seem to get any new headers showing up

I've added this to user.js, and id5 is correct:

user_pref("mail.identity.id5.headers", "archive, supercedes");

I will take a look next week. But even if no headers show up, it's a separate issue. This bug is about mail.compose.other.header and typing the header content manually in the compose window. As I understand, mail.identity.id5.headers are default custom headers appended to every sent message.

I agree.

@Magnus Melin:
There must be only one pref "mail.identity.id5.headers".
And there is no space allowed in the value.

user_pref("mail.identity.id5.headers", "archive,supercedes");
user_pref("mail.identity.id5.header.archive", "X-No-Archive: yes");
user_pref("mail.identity.id5.header.supercedes", "Supercedes: <1234@example.com>");

This works for me. But this wasn't broken at all. ;-)

(In reply to Magnus Melin [:mkmelin] from comment #29)

user_pref("mail.compose.other.header", "Approved,Supercedes");

Then I write "yes" in the Approved header and try to do Send later. This
results in

JavaScript error: resource:///modules/jsmime/jsmime.js, line 3409:
TypeError: cannot use 'in' operator to search for "email" in "yes"

I can confirm this with the Approved header. It has a special meaning.
I guess it must be an email address. But that doesn't work either.

This was already broken before, see: Bug 1204740

Then I write "yes" in the Approved header and try to do Send later. This

I guess it must be an email address. But that doesn't work either.

https://dxr.mozilla.org/comm-central/rev/2a29ee0adb310b54a6a2df72034953fed8f2b043/comm/mailnews/mime/jsmime/jsmime.js#167

// From RFC 5536:
addHeader("Approved", parseAddress, writeAddress);

JFTR

(In reply to Alfred Peters from comment #30)

(In reply to Magnus Melin [:mkmelin] from comment #29)

This was already broken before, see: Bug 1204740
=> Bug 1180209 Comment 8

Now I see more upcoming problems.

• Can we handle an email address for newsgroups and plain strings for email?
• What happens to passwords/strings with 8-bit chars? Do the mailing list servers decode a MIME encoded string?

(In reply to Magnus Melin [:mkmelin] from comment #29)

Comment on attachment 9171319 [details] [diff] [review]
1658890-no-pill.patch

Review of attachment 9171319 [details] [diff] [review]:

JavaScript error: resource:///modules/jsmime/jsmime.js, line 3409:
TypeError: cannot use 'in' operator to search for "email" in "yes"

Ok, finally all these /special/ headers will throw the above error, because they need an address (like To etc.) output:
https://dxr.mozilla.org/comm-central/search?q=addHeader+parseAddress++file%3Ajsmime.js&redirect=false

@Ping Chen: Could you please change the field type accordingly.

Because of the Approved header:
It would be nice to set the field type based on the account type:

• Newsgroup account -> address data
• Email account -> plain text

That should be enough to select the right parser in jsmime.js.
If you wish, I'll do the changes in jsmime.js in Bug 1180209, , but feel free to do it yourself.

• Fix can't access property "focus", container.querySelector(...) is null of comment 29
• Revert to use setRawHeader to fix Approved header

From https://searchfox.org/comm-central/source/mailnews/mime/public/msgIStructuredHeaders.idl#175-176, setRawHeader expects the arguments to be ACString. When using setRawHeader in JS, the header value is by default a UTF-16 string. This caused the encoding error of comment 14. This patch adds a utf16StringToBinaryString to convert header value before passing it to setRawHeader. This should fix all known problems and bug 1180209, please confirm.

Adds browser_customHeaders.js to test encoding of non-ASCII custom header value and Approved header. Try run: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=031bab14e4d04197998ec37b610911&selectedTaskRun=aILavSBFRQa0yCrEAcDsaA.0

Updates to comment 36.

Please change setRawHeader to take AUTF8String instead and then I think things should just work I think.

It works on my local. Let's see if Try run passes https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=c5b5c8dc81af7a601cceb47ec80e66d2fdd67801

(In reply to Ping Chen (:rnons) from comment #37)

Created attachment 9171643 [details] [diff] [review]
1658890-no-pill.patch

I'm happy with it.

Update to comment 39.

Comment on attachment 9171835 [details] [diff] [review]
1658890-no-pill.patch

[Approval Request Comment]
Regression caused by (bug #): bug 440377
User impact if declined: Custom header name becomes Null in sent mail
Testing completed (on c-c, etc.): Completed
Risk to taking this patch (and alternatives if risky): Type of header value in setRawHeader is changed from ACString to AUTF8String, but all tests passed, so it should be OK.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/ca5683d5593d
Fix null custom header name when sending message. r=mkmelin

Comment on attachment 9171835 [details] [diff] [review]
1658890-no-pill.patch

[Triage Comment]
approved for beta

Thunderbird 81.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/2118330f7750

On second thought, the changes to setRawHeader() should be reversed and instead a separate interface for use in JS should be created. From the JS call site https://hg.mozilla.org/comm-central/rev/ca5683d5593d#l3.42, no UTF-8 raw byte string is passed but rather a UTF-16-encoded JS string which should be mapped onto AString. This is similar to the difference between parseEncodedHeader() and parseEncodedHeaderW(). Please read
https://searchfox.org/comm-central/rev/7156143da17c283114591163b3074e622484ee6e/mailnews/mime/public/nsIMsgHeaderParser.idl#96

Not sure that's accurate. UTF8String and AString are just the UTF-8 and UTF-16 versions for idl smart string parameters. We're just passing around strings here so why would it make a difference?

Yes, the charset param should be removed.

If you remove the charset parameter, you should also rename the function since you're visiting all the call sites anyway.

As was said, the re-dedicated function now takes a AUTF8String parameter instead of a ACString parameter. For JS callers that means that XPCOM will have to do an UTF-16 to UTF-8 conversion, and then back to UTF-16 since the function itself is provided in JS. AUTF8Sting is a single-byte interface whereas AString is a two-byte interface. What is implemented works, but comes at the cost of two runtime conversions. You might want to check with an IDL expert here.

Remove the charset argument from setRawHeader function.

About the function name, I think the raw refers to the header value being raw/unstructured, that's why parseStructuredHeader is used.

About the performance, I think the conversion happens when the value is used (going out of xpconnect), not when the function is called (going into xpconnect).

From https://searchfox.org/mozilla-central/source/js/xpconnect/src/nsXPConnect.cpp#821,831,842,847, when an xpcom function is called from JS, XPCVariant::newVariant is used, but no conversion happens. Then if this xpcom function is implemented in JS, XPCVariant::VariantDataToJS is used.

From https://searchfox.org/mozilla-central/source/js/xpconnect/src/XPCVariant.cpp#379,385,388, if the variant->GetAsJSVal is already a JS primitive value, it's returned directly without conversion.

In the case of setRawHeader, when called from C++, nsACString ---> XPConnect ---> JS UTF16, the conversion was previously done by jsmime.headerparser.convert8BitHeader, and now by xpconnect, no performance degradation. When called from JS, JS UTF16 ---> XPConnect ---> JS UTF16, no conversion happens, performance is improved.

Of course this is just my understanding, I'm not an expert.

To be 100% clear: It's likely that newsgroups with UTF-8 names are already broken after the first patch. If you need examples, turn to bug 1389762 for examples (news.newsfan.net). Apparently there are many newsgroups with non-ASCII names encoded in UTF-8 and also other charsets (but the latter don't work).

I don't think non UTF-8 group names are allowed no. https://searchfox.org/comm-central/rev/7156143da17c283114591163b3074e622484ee6e/mailnews/news/src/nsNNTPProtocol.cpp#891

Anyway, getRawHeader returns AUTF8String which it got from jsmime which treated that all as a js string. There's no "raw bytes" here AFAIKT.

https://searchfox.org/comm-central/rev/7156143da17c283114591163b3074e622484ee6e/mailnews/mime/public/msgIStructuredHeaders.idl#89
https://searchfox.org/comm-central/rev/7156143da17c283114591163b3074e622484ee6e/mailnews/mime/src/MimeJSComponents.jsm#108

(note that nntp is pretty much busted on trunk for other reasons - bug 1661955)

Right, non-UTF8 names are not supported, but UTF-8 names are. As for getRawHeader():
https://searchfox.org/comm-central/rev/7156143da17c283114591163b3074e622484ee6e/mailnews/mime/jsmime/jsmime.js#1873
If in doubt ask :jcranmer. It appears that setRawHeader() and getRawHeader() are a matched pair, and now the semantic of one of them was changed. Maybe NNTP still works on beta, or you can do a try build of ESR.

Thanks for your interest in this bug.

To be 100% clear: It's likely that newsgroups with UTF-8 names are already broken after the first patch. If you need examples, turn to bug 1389762 for examples (news.newsfan.net).

There is no way my last week's patch can cause a 3-years old bug. I appreciate if you want to contribute some test cases to https://searchfox.org/comm-central/source/mailnews/compose/test/unit/test_messageHeaders.js#309

Right, non-UTF8 names are not supported, but UTF-8 names are. As for getRawHeader():
https://searchfox.org/comm-central/rev/7156143da17c283114591163b3074e622484ee6e/mailnews/mime/jsmime/jsmime.js#1873
If in doubt ask :jcranmer. It appears that setRawHeader() and getRawHeader() are a matched pair, and now the semantic of one of them was changed.

Seems to me the getRawHeader function in jsmime is not related to msgIWritableStructuredHeaders.getRawHeader at all.

I would be happy to fix if you can prove something is broken by 1658890-no-pill.patch, for other problems, please consider filing new bugs.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/25dd31b9c909
followup - Remove charset from setRawHeader. r=mkmelin

Reference to: https://bugzilla.mozilla.org/show_bug.cgi?id=1661458

With TB 78.2.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Thunderbird/78.2.1

In header I see the same as before:
Null: 5b30489b-bc40.............

Supersedes don't work

In my user.js
user_pref("mail.compose.other.header", "Supersedes");

What should I do now?

(In reply to Ping Chen (:rnons) from comment #56)

There is no way my last week's patch can cause a 3-years old bug. I appreciate if you want to contribute some test cases to https://searchfox.org/comm-central/source/mailnews/compose/test/unit/test_messageHeaders.js#309

You misunderstood. The three-year-old bug is about raw non-UTF-8 newsgroups. We believe that now UTF-8 newsgroups are broken. Have you tested that?

Seems to me the getRawHeader function in jsmime is not related to msgIWritableStructuredHeaders.getRawHeader at all.

Isn't msgIStructuredHeaders.getRawHeader() implemented here:
https://searchfox.org/comm-central/rev/e75f551c5deb7740ac08a13cb9e488b1c4ed3f82/mailnews/mime/jsmime/jsmime.js#1892
What am I missing and what is msgIWritableStructuredHeaders.getRawHeader?

:FritzS, it's not uplifted to esr78 yet. Can you please try again with beta or nightly?

Seems to me the getRawHeader function in jsmime is not related to msgIWritableStructuredHeaders.getRawHeader at all.

Isn't msgIStructuredHeaders.getRawHeader() implemented here:
https://searchfox.org/comm-central/rev/e75f551c5deb7740ac08a13cb9e488b1c4ed3f82/mailnews/mime/jsmime/jsmime.js#1892
What am I missing and what is msgIWritableStructuredHeaders.getRawHeader?

You missed https://searchfox.org/comm-central/source/mailnews/mime/src/MimeJSComponents.jsm#185 and https://searchfox.org/comm-central/source/mailnews/mime/src/MimeJSComponents.jsm#108

That was missed indeed, apologies! Please take a look at bug 1662350. We couldn't get to the stage to post to Test.UTF8.测试1 since the subscription dialogue was already broken (which may be unrelated). Posting there in TB 78 still appears to work (but the message never appears in the group, perhaps one needs an account there).

This is 1658890-charset.patch rebased to the esr78 repo. I'm wondering is it really necessary to uplift this patch, since it doesn't fix any bug.

That one probably isn't strictly needed for 78 since it's just code clean-up. Does the main patch (the other one) apply cleanly to 78?

(In reply to Magnus Melin [:mkmelin] from comment #64)

Does the main patch (the other one) apply cleanly to 78?

Yes, a hunk is resolved automatically.

applying 1658890-no-pill.patch
patching file mail/base/content/mailWidgets.js
Hunk #1 succeeded at 2155 with fuzz 1 (offset 10 lines).
now at: 1658890-no-pill.patch

(In reply to Ping Chen (:rnons) from comment #63)

This is 1658890-charset.patch rebased to the esr78 repo. I'm wondering is it really necessary to uplift this patch, since it doesn't fix any bug.

Avoids merge conflicts if further patches in the affected areas need to be uplifted.

(In reply to p≡p Project from comment #52)

To be 100% clear: It's likely that newsgroups with UTF-8 names are already broken after the first patch.

That statement is wrong, I tested it on a Daily build and it still works.

(In reply to p≡p Project from comment #62)

Please take a look at bug 1662350.

That bug is invalid.

Apologies!

Comment on attachment 9171835 [details] [diff] [review]
1658890-no-pill.patch

[Triage Comment]
Approved for esr78

https://hg.mozilla.org/releases/comm-esr78/rev/5b5d74460772
Thunderbird 78.2.2:
https://hg.mozilla.org/releases/comm-esr78/rev/aaaa4c8a07e0

Backout Thunderbird 78.2.2 for causing crash:
https://hg.mozilla.org/releases/comm-esr78/rev/b84e7103a735

Caused a crash in bct3 tests on all platforms when uplifted to c-esr78.
https://treeherder.mozilla.org/#/jobs?repo=comm-esr78&selectedTaskRun=Xf7CHVzfSkSB2IqGs-KWtQ.0&revision=aaaa4c8a07e0f41c6f4c571cd560552cbe84e978

Verified backout with try jobs:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=c4efa77787dc6a456320c2299db5749f546395b7
and
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=8a461c2cbd7e43537dd7505d475e51c96d27b6ce

The second try job included only the no-pill patch to see if the crash was caused by the charset patch somehow. It failed as well. bct3 was green without either patch.

Ping, can you take a look? We didn't see this error on beta.

(In reply to Rob Lemley [:rjl] from comment #71)

Caused a crash in bct3 tests on all platforms when uplifted to c-esr78.

Saw JavaScript Error: "uncaught exception: [fluent] Missing translations in en-US: remove-address-row-type." in the log. That's strange, it worked on my local when preparing 1658890-charset-esr78.patch. And the remove-address-row-type entry can be found in https://hg.mozilla.org/releases/comm-esr78/file/aaaa4c8a07e0f41c6f4c571cd560552cbe84e978/mail/locales/en-US/messenger/messengercompose/messengercompose.ftl#l8.

Anyway, I found the code throwing the error is redundant, the tooltip will be overwritten by https://hg.mozilla.org/releases/comm-esr78/file/aaaa4c8a07e0f41c6f4c571cd560552cbe84e978/mail/components/compose/content/MsgComposeCommands.js#l4176. After removing the code, browser_customHeaders pass on my local again.

Is this going to ship in the next release? It would be handy to be able to add custom headers again.

Yes, this can make it in for 78.2.2.

Re-land:
https://hg.mozilla.org/releases/comm-esr78/rev/5b5d74460772
https://hg.mozilla.org/releases/comm-esr78/rev/aaaa4c8a07e0
and apply attachment 9173926 [details] [diff] [review].

Thunderbird 78.2.2:
https://hg.mozilla.org/releases/comm-esr78/rev/fa31b3bb1a1c
https://hg.mozilla.org/releases/comm-esr78/rev/57b8dd793d00
https://hg.mozilla.org/releases/comm-esr78/rev/7ed237570e2a