(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 that source code using SearchFox: https://searchfox.org/comm-central/search?path=&q=pillifyRecipients From searchfox search results, you can 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. 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! ;-)
Bug 1688336 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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 that source code using SearchFox: https://searchfox.org/comm-central/search?path=&q=pillifyRecipients From searchfox search results, you can 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. 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! ;-)
(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 that 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. 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! ;-)
(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. 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! ;-)
(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.~~ [Edit: uplifted to 78.7.1 on 2021-02-03 following my approval-comm-esr78 request in Bug 1682147 Comment 26] ~~So our next step is to request that uplift in order to bandaid-fix this bug.~~ 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! ;-)
(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! ;-)
(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! ;-)