1688336 - A custom header breaks sending a message

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[bodqhrohro]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Thunderbird/85.0

Steps to reproduce:

1. Set mail.compose.other.header to X-Debbugs-Cc in about:config.
2. Open the Message Compose Window.
3. Type in valid To, Subject, Body...
4. Hit the chevron and add a X-Debbugs-Cc header.
5. Fill the field.
6. Hit "Send".

Actual results:

No results visible in UI, just a stuck window.

Uncaught TypeError: input is null
pillifyRecipients chrome://messenger/content/messengercompose/MsgComposeCommands.js:4858
SendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:4865
doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:978
doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:1174
goDoCommand chrome://global/content/globalOverlay.js:101
oncommand chrome://messenger/content/messengercompose/messengercompose.xhtml:1
MsgComposeCommands.js:4858:9
An error occurred executing the cmd_sendButton command: [Exception... "[JavaScript Error: "input is null" {file: "chrome://messenger/content/messengercompose/MsgComposeCommands.js" line: 4858}]'[JavaScript Error: "input is null" {file: "chrome://messenger/content/messengercompose/MsgComposeCommands.js" line: 4858}]' when calling method: [nsIController::doCommand]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 101" data: yes] globalOverlay.js:104
goDoCommand chrome://global/content/globalOverlay.js:104
oncommand chrome://messenger/content/messengercompose/messengercompose.xhtml:1

Expected results:

Sending messages with this header worked fine before.

Comment 2

[Alfred Peters [:infofrommozilla]]

I can confirm this for TB78.6.1 but TB trunk build (alpha) works fine for me.
So it's probably already fixed by another Bug.

Comment 3

[Alfred Peters [:infofrommozilla]]

bodqhrohro you created the bug for TB85.
Is this a beta TB?
Which version is it exactly?

Comment 4

[stedaho]

I can also confirm the issue for TB78.6.1. In TB78.6.0 everything worked as expected. I did not test it with newer (alpha/beta) versions.

tacliat, could you provide in which version you noticed the issue?

Comment 5

[tacliat]

same versions as reported above.

Comment 6

[Magnus Melin [:mkmelin]]

Confirmed trunk works fine.

Comment 7

[bodqhrohro]

(In reply to Alfred Peters from comment #3)

bodqhrohro you created the bug for TB85.
Is this a beta TB?
Which version is it exactly?

Yes, 85.0b3.

Comment 9

[Thomas D. (:thomas8)]

Attachment: Screenshot: Using searchfox to identify involved bugs starting from console error information

(In reply to Alfred Peters from comment #2)

I can confirm this for TB78.6.1 but TB trunk build (alpha) works fine for me.
So it's probably already fixed by another Bug.

You might be interested how to identify bugs which introduced a regression like this bug, as well as "another bug" which fixed this as you correctly assumed... The top line of the error message in comment 0 leads directly to the two bugs involved, so below I'll explain how to find them.

(In reply to bodqhrohro from comment #0)
Hi bodqhrohro, thank you for reporting this including the error message in comment 0.

Uncaught TypeError: input is null
pillifyRecipients chrome://messenger/content/messengercompose/MsgComposeCommands.js:4858

The error message references the function pillifyRecipients() and the containing file and line.
You can find the function (or the file) in the source code using SearchFox:
https://searchfox.org/comm-central/search?path=&q=pillifyRecipients

From searchfox search results, you will find the current source code in trunk:

https://searchfox.org/comm-central/rev/d612a97367b16d73a7589524a57eb4e7dae90236/mail/components/compose/content/MsgComposeCommands.js#4863-4874

If you hover the left side of the code, you'll find the "blame" column which shows the last bug which has touched the hovered line of code. Screenshot shows the bug which introduced this function (and this bug):

Bug 1674054 - All non-pillified recipients (pasted, typed) silently discarded when clicking [Send] button directly

For the offending line 4858 (marked red in the screenshot) which is ultimately raising the error in TB 78 (as per error message), you can see that the blame color is different, dark-grey. So another bug has last touched this, likely the one which fixed this for Daily/Trunk:

Bug 1682147 - command+enter in addressing area does not send message

And indeed, if you click on "Show annotated diff" in the dark blame bubble of line 4858, the last change was this:

-     if (input.value.trim()) {
+     if (input?.value.trim()) {

That question mark prevents the bug in Daily/Trunk, as it will short-circuit the conditionial to 'undefined' if input is null (obviously you cannot retrieve the value of a non-existing input, and input is null because other header fields do not have an autocomplete type of input).

Unfortunately, Bug 1682147 was not uplifted to TB 78, not sure why.
So our next step is to request that uplift in order to bandaid-fix this bug.
[EDIT: Uplifted to 78.7.1 on 2021-02-03 following my approval-comm-esr78 request in Bug 1682147 Comment 26]

The underlying problem is that the code does not sufficiently reflect the possible existence of custom headers, which will need some extra awareness/attention.

So now you know! ;-)

Comment 10

[Thomas D. (:thomas8)]

Per my analysis in comment 9, this was regressed by:

Bug 1674054 - All non-pillified recipients (pasted, typed) silently discarded when clicking [Send] button directly

De facto fixed on Daily/trunk by:

Bug 1682147 - command+enter in addressing area does not send message

We should probably uplift that to get this bandaid-fix into TB 78 asap.

Comment 11

[Alfred Peters [:infofrommozilla]]

(In reply to Thomas D. (:thomas8) from comment #9)

You might be interested how to [...]

Ah yes, thanks for the interesting explanation.

So now you know! ;-)

But, needinfo?(info[...]@gmail.com) - do you still have a wish to me?

Comment 12

[Thomas D. (:thomas8)]

(In reply to Alfred Peters from comment #11)

But, needinfo?(info[...]@gmail.com) - do you still have a wish to me?

Oh no, sorry, that's alright Alfred, the needinfo was just about getting your attention between all the bugmail, and knowing if you've seen my comment... I do have a wish FOR you and all the other helpful people out there: Stay safe n healthy, and feel great because your support for Thunderbird makes a difference! Thanks.

Comment 13

[Thomas D. (:thomas8)]

This should be fixed since TB 78.7.1, less than 2 weeks after this was filed.

bodqhrohro, pls confirm: Does sending messages with custom headers work for you again?

Uplifted to 78.7.1 on 2021-02-03 following my approval-comm-esr78 request in Bug 1682147 Comment 26.
Incidentally fixed by adding optional chaining operator to an expected autocomplete input (Bug 1682147 Comment 28).
We should select the right address rows in the first place: Filed followup bug 1696789.

Comment 14

[bodqhrohro]

Works for me in 87.0b2, thanks.