cannot send message

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Steps to reproduce:

I noticed after updating to 52.1.1 64-bit on Linux Mint 17.3 Cinnamon 64-bit (Cinnamon v 2.8.8) the send button fails with error messages in the debug log under certain circumstances.

Everything works fine when using an account tied to google
The failure is specific to an office365 account that I've setup through a local exchange relay program called davmail

The issue does not present when composing new messages, only on replying to messages.

Send button, ctrl+enter, file Send do not work

I have tried running in safe-mode and the error persists

This error presented after an update to 52.1.1 I performed today. I do not remember prior version of TB.

Actual results:

Mail is not sent and errors are logged in the debug window:

NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists] MsgComposeCommands.js:4451
An error occurred executing the cmd_sendWithCheck command: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 4451" data: no] globalOverlay.js:103
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists] MsgComposeCommands.js:4451
An error occurred executing the cmd_sendButton command: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 4451" data: no] globalOverlay.js:103

Expected results:

Mail should have been delivered.

Aceman, something for you to look at.

This is not MailListNameExists :)

Anyway, what was your TB version before the update?
It would be great to find out which line is producing that error.
It should be either:
LookupAddressBook(recipientsList)
or
recipient.mDirectory->GetReadOnly(&readOnly);
Those could produce NS_ERROR_NOT_IMPLEMENTED that is then returned to the caller.

Are you using some special Addressbook type or an addon for it?

Does it happen on all replied messages or only some specific one that may contain some unusual recipient, e.g. a group ("name:;" or similar) ?

I do not remember what my prior TB version was. Is there a log file I can find that information in?

I am not using any special address book addon. I've got a program called davmail which sits between TB and exchange which allows me to use standard TB functionality to talk to exchange through it's MAPI interface (as my company has POP/IMAP locked down) but from a TB side it is stock.

This usually happens when I attempt to reply to messages sent through exchange. Happens with individual recipients, lists of recipients and distribution lists. Does not appear to happen with "new" messages, nor are my gmail accounts impacted.

Is there a debug or trace level I can set to provide you with more information about which function is being called?

(priority is for developers)

I have the same issue.
For me it happens always for different accounts (not only google).
The bug was introduced in Thunderbird version 52.1
You can find my original ticket here: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1691479

https://hg.mozilla.org/comm-central/diff/642cfedbc637/mailnews/compose/src/nsMsgCompose.cpp

Looks like that commit introduced the nsMsgCompose::ExpandMailingLists() function and modified MsgComposeCommands.js to call it, but looking at nsMsgCompose.h, I don't see ExpandMailingLists() declared, which probably affects the reachability of that method. What's puzzling is how the automated tests (e.g., test_expandMailingLists.js) pass? Oh, expandMailingLists() is defined in nsIMsgCompose.idl ...

I guess that in case of declaration problem, Thunderbird wouldn't be able to send messages at all. However, sometimes (rarely), after start, it works properly and sends e-mails. Unfortunately, being left for a while in background, it restarts to have the described earlier send isssue.

same probleme here with thunderbird-52.2.0-1.el7.centos.x86_64

NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]

An error occurred executing the cmd_sendButton command: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 4456" data: no]

it happens only for certain email destination addresses
is there a solution identified ?
is this related to adressBooks ?

Thanks .

Same here with 52.1.1, 52.2.1 and lastest build 54.0b3.
Win 7 64-bit

This is a very critical bug for me as it renders TB nearly unusable as almost no emails can be answered or sent !!!!

TypeError: aDocumentNode is undefined[Weitere Informationen] msgHdrViewOverlay.js:1391:1
 UpdateExtraAddressProcessing chrome://messenger/content/msgHdrViewOverlay.js:1391:1
 updateExtraAddressProcessing chrome://messenger/content/mailWidgets.xml:907:17
 OnAddressBookDataChanged/< chrome://messenger/content/msgHdrViewOverlay.js:395:9
 forEach self-hosted:251:13
 OnAddressBookDataChanged chrome://messenger/content/msgHdrViewOverlay.js:389:3
 AddressBookListener.onItemPropertyChanged chrome://messenger/content/msgHdrViewOverlay.js:384:7
 Enigmail.msg.determineSendFlags chrome://enigmail/content/enigmailMsgComposeOverlay.js:1769:7
 Enigmail.msg.setIdentityDefaults chrome://enigmail/content/enigmailMsgComposeOverlay.js:273:7
 Enigmail.msg.msgComposeReset chrome://enigmail/content/enigmailMsgComposeOverlay.js:623:7
 Enigmail.msg.composeStartup chrome://enigmail/content/enigmailMsgComposeOverlay.js:160:5
 _enigmail_composeStartup chrome://enigmail/content/enigmailMsgComposeOverlay.js:4480:5
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists] MsgComposeCommands.js:4456
 expandRecipients chrome://messenger/content/messengercompose/MsgComposeCommands.js:4456:3
 GenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:2930:5
 SendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:3270:3
 defaultController.commands.cmd_sendButton.doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:700:11
 defaultController.doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:872:5
 goDoCommand chrome://global/content/globalOverlay.js:100:7
 oncommand chrome://messenger/content/messengercompose/messengercompose.xul:1:1
An error occurred executing the cmd_sendButton command: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 4456" data: no] globalOverlay.js:103
 goDoCommand chrome://global/content/globalOverlay.js:103:5
 oncommand chrome://messenger/content/messengercompose/messengercompose.xul:1:1

*** Bug 1378293 has been marked as a duplicate of this bug. ***

For me the issue shows up when trying to sent a new message or answer/answer all.
Most of the time i need to use the Web interface of my provider.
TB still receives mails but nearly no new mails can be sent.

Can we increase importance of this bug to critical as it's nearly impossible to sent emails at least for me.
We use Thunderbird in the company and only ~5 out of 100 emails can be sent through Thunderbird while the rest goes through web interface of email cient. Upcoming recommondation is to migrate to Outlook.

People who can reproduce this bug, can you please answer the following questions:

1) What language TB are you using? Just want to get an idea of the localizations that can reproduce this bug.

2) What Text Encoding are you trying to send messages in when the send fails? (When composing the message that won't send, look at Options > Text Encoding, and report what it is set to.)

Comment #9 mentions Enigmail. Can you reproduce the problem with Enigmail disabled?

As for switching to Outlook: Well, you could just temporarily go back to TB 45.8. Or for the money that you're going to spend on Outlook, hire someone to analyse the TB problem.

I have Enigmail enabled, and cannot reproduce. I suspect the issue might be around a change in L10n/i18n.

The problem exists with or without Enigmail enabled.

1) TB German language
2) Text encoding -> Unicode (same for Western)

(In reply to :Dossy Shiobara from comment #13)
> People who can reproduce this bug, can you please answer the following
> questions:
>
> 1) What language TB are you using? Just want to get an idea of the
> localizations that can reproduce this bug.
>
> 2) What Text Encoding are you trying to send messages in when the send
> fails? (When composing the message that won't send, look at Options > Text
> Encoding, and report what it is set to.)

I'm using English. Text encoding is unicode. Please let me know if you need more details.

coxmatthew, AllUses:

How did you install the version of TB you're on? In-app upgrade from previous version of TB, or fresh complete install via download of installer package? Or, some other method (built from source, etc.)?

I'm wondering if the problem is a bad MAR file which got applied during a partial update upgrade within TB. If possible, can you do a full install using a freshly downloaded installer package, and see if you can still reproduce the bug?

Also, what is your account setup? In "Composition & Addressing" what do you have selected under Addressing "When looking up addresses:" - Global LDAP server (option #1) or a different LDAP server (option #2)? If option #1, what do you have in Preferences > Composition > Addressing tab - Local Address Books and/or Directory Server? I'm looking to see if either or both of you have LDAP directory configured for use or not.

This was a in-app upgrade from prev. version 52.1.1 where the issue already exists.
Fresh install might be a little bit tricky from timing perspective but i'll check.

(In reply to :Dossy Shiobara from comment #18)
> coxmatthew, AllUses:
>
> How did you install the version of TB you're on? In-app upgrade from
> previous version of TB, or fresh complete install via download of installer
> package? Or, some other method (built from source, etc.)?
>
> I'm wondering if the problem is a bad MAR file which got applied during a
> partial update upgrade within TB. If possible, can you do a full install
> using a freshly downloaded installer package, and see if you can still
> reproduce the bug?

It's option #2 - company LDAP

(In reply to :Dossy Shiobara from comment #19)
> Also, what is your account setup? In "Composition & Addressing" what do you
> have selected under Addressing "When looking up addresses:" - Global LDAP
> server (option #1) or a different LDAP server (option #2)? If option #1,
> what do you have in Preferences > Composition > Addressing tab - Local
> Address Books and/or Directory Server? I'm looking to see if either or both
> of you have LDAP directory configured for use or not.

AllUses: Can you temporarily disable LDAP and only use the Local Address Book and see if you can still reproduce the bug?

Issue still exists after switching to local address book only (LDAP disabled globally and on account level) and restart of TB.

(In reply to :Dossy Shiobara from comment #22)
> AllUses: Can you temporarily disable LDAP and only use the Local Address
> Book and see if you can still reproduce the bug?

AllUses: Okay, thanks for helping to rule that out. I didn't think that was the culprit, but it was good to verify.

If you can find the time to do a fresh clean install of the latest TB, and confirm whether the bug persists, that would be helpful. Also, in your specific case, if you could try a fresh clean install of TB English (US) instead of TB (German), that might shed some light on the situation, as well. The full list of localized builds can be seen here:

https://www.mozilla.org/en-US/thunderbird/all/

(In reply to :Dossy Shiobara from comment #18)
> coxmatthew, AllUses:
>
> How did you install the version of TB you're on? In-app upgrade from
> previous version of TB, or fresh complete install via download of installer
> package? Or, some other method (built from source, etc.)?
>
> I'm wondering if the problem is a bad MAR file which got applied during a
> partial update upgrade within TB. If possible, can you do a full install
> using a freshly downloaded installer package, and see if you can still
> reproduce the bug?

My installation is done through package manager on Linux Mint

(In reply to :Dossy Shiobara from comment #19)
> Also, what is your account setup? In "Composition & Addressing" what do you
> have selected under Addressing "When looking up addresses:" - Global LDAP
> server (option #1) or a different LDAP server (option #2)? If option #1,
> what do you have in Preferences > Composition > Addressing tab - Local
> Address Books and/or Directory Server? I'm looking to see if either or both
> of you have LDAP directory configured for use or not.

Mine is also option #2, which is my company LDAP

coxmatthew, would you mind trying uninstalling the Linux Mint package installed version, and installing the Mozilla-provided binary, just to see if there's a difference? If you can still reproduce the issue with the official Mozilla binaries, that would be useful to know.

You can download the official build here:

https://www.mozilla.org/en-US/thunderbird/all/

If you can still reproduce the problem, then I'll go and set up a VM here with "Linux Mint 17.3 Cinnamon 64-bit (Cinnamon v 2.8.8)" and see if I can reproduce the problem here, as well. Also, you said you cannot reproduce the problem when using a Google/Gmail account over IMAP/SMTP, but you can when using an account through DavMail IMAP/SMTP when DavMail is connected to Office365? I basically want to replicate your environment so that I can reproduce the problem on my own, so I just want to confirm the details.

I went ahead and did a fresh install of Linux Mint 17.3 Cinnamon 64-bit, which installed Thunderbird 52.2.1 (64-bit). I then grabbed davmail-linux-x86_64-4.8.0-2479.tgz and ran it with all out-of-the-box settings. I then set up a new account in TB, pointing at localhost to use davmail, and successfully connected to my Office 365 account. I was able to reply to messages in my inbox successfully, without issue.

Of course, since this was a fresh install of Mint, it was a fresh install of TB, as well. Not sure if there's a way I can (easily) install an older version of TB, then let it update itself to the latest version. Will try that next, but just wanted to update everyone that I still haven't been able to reproduce this, so far.

Continuing my attempts to reproduce this under Linux Mint 17.3, I went and grabbed TB 52.0, from here:

https://ftp.mozilla.org/pub/thunderbird/releases/52.0/linux-x86_64/en-US/thunderbird-52.0.tar.bz2

I tested replying to an email through davmail+office365, it worked as expected.

TB updated itself to 52.2.1, and I tested the same reply, and it worked as expected.

I don't have convenient access to a Win7 64-bit machine, so I can't attempt to reproduce this on that platform at the moment.

Did a fresh install of TB 52.2.1 english (US) but the issue still exists.
Same for TB 52.2.1 german.
For both i used my existing profile.

And on a new profile? Start Thunderbird with -p to create one. I'm sure it will work, so there is something in the old profile that makes it fail. We need to find that something.

AllUses: yes, Jorg makes an excellent point - can you reproduce this with a clean new profile with just the problematic account in question added, and nothing else? If you can still reproduce, then try starting TB in safe mode (Help > Restart with Add-ons Disabled...) using the new profile and see if you can still reproduce.

Using a new profile may take some while as i need to do some work in the meantime.
However, if it works with a fresh new profile then TB 52 doesn't support pre-52 profiles at least with a specific setting in it. Wonder which setting this could be.

(In reply to Jorg K (GMT+2) from comment #31)
> And on a new profile? Start Thunderbird with -p to create one. I'm sure it
> will work, so there is something in the old profile that makes it fail. We
> need to find that something.

Hi, this is my first post, so sorry if i screw this, but the only way to avoid this with my existing profile was disabling the "look for matching entries" in "Local Address Books".
When reply to all, it looks that it cant find all address in local addres books and stops sending emails, but doesnt paint address in red, just stops sending and give me the same 2 errors:

"NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists] MsgComposeCommands.js:4451
An error occurred executing the cmd_sendButton command: [Exception... "Component returned failure code: 0x80004001
(NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 4451" data: no]"

After disabling that check, the send button is working as expected.
Maybe that helps you, maybe not.
Thanks.

(In reply to gergilar from comment #34)
> Hi, this is my first post, so sorry if i screw this, but the only way to
> avoid this with my existing profile was disabling the "look for matching
> entries" in "Local Address Books".
> When reply to all, it looks that it cant find all address in local addres
> books and stops sending emails, but doesnt paint address in red, just stops
> sending and give me the same 2 errors:
>
> "NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001
> (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]
> MsgComposeCommands.js:4451
> An error occurred executing the cmd_sendButton command: [Exception...
> "Component returned failure code: 0x80004001
> (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult:
> "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame ::
> chrome://messenger/content/messengercompose/MsgComposeCommands.js ::
> expandRecipients :: line 4451" data: no]"
>
> After disabling that check, the send button is working as expected.
> Maybe that helps you, maybe not.
> Thanks.

gergilar,

I have just tried this and it does not solve my problem. I'm glad it worked for you but there is something deeper at play here.

(In reply to :Dossy Shiobara from comment #27)
> coxmatthew, would you mind trying uninstalling the Linux Mint package
> installed version, and installing the Mozilla-provided binary, just to see
> if there's a difference? If you can still reproduce the issue with the
> official Mozilla binaries, that would be useful to know.
>
> You can download the official build here:
>
> https://www.mozilla.org/en-US/thunderbird/all/
>
> If you can still reproduce the problem, then I'll go and set up a VM here
> with "Linux Mint 17.3 Cinnamon 64-bit (Cinnamon v 2.8.8)" and see if I can
> reproduce the problem here, as well. Also, you said you cannot reproduce
> the problem when using a Google/Gmail account over IMAP/SMTP, but you can
> when using an account through DavMail IMAP/SMTP when DavMail is connected to
> Office365? I basically want to replicate your environment so that I can
> reproduce the problem on my own, so I just want to confirm the details.

(In reply to AllUses from comment #33)
> Using a new profile may take some while as i need to do some work in the
> meantime.
> However, if it works with a fresh new profile then TB 52 doesn't support
> pre-52 profiles at least with a specific setting in it. Wonder which setting
> this could be.
>
> (In reply to Jorg K (GMT+2) from comment #31)
> > And on a new profile? Start Thunderbird with -p to create one. I'm sure it
> > will work, so there is something in the old profile that makes it fail. We
> > need to find that something.

I am also planning on trying a new profile, but things are crazy for me at work too. Will update as soon as possible as I'd like to get this bug resolved.

(In reply to gergilar from comment #34)
Hmm, you're saying that
Tool > Options, Composition, Addressing, "look for matching entries" in "Local Address Books" turned off will fix the problem. Well, I have it turned *on* and I see no problem.

(In reply to gergilar from comment #34)

gergilar, would you be able to also test creating a new TB profile and see if that fixes the problem for you? You can create a new profile by starting TB with the "-P" command line option to bring up the Profile Manager, then click "Create Profile" to create a new profile. Then, just add the one mail account that's giving you problems, and see if you can still reproduce the bug?

Thanks!

Unfortunately it doesn't work for me too.

However, once i add all recipients (reply-to-all) to my local address book it magically works.
As soon as there is one recipient not known by local address book the send button does not work.
Haven't checked if LDAP plays a role here but might do as soon as i got a mail from non-LDAP.

(In reply to gergilar from comment #34)
> Hi, this is my first post, so sorry if i screw this, but the only way to
> avoid this with my existing profile was disabling the "look for matching
> entries" in "Local Address Books".
> When reply to all, it looks that it cant find all address in local addres
> books and stops sending emails, but doesnt paint address in red, just stops
> sending and give me the same 2 errors:
>
> "NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001
> (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]
> MsgComposeCommands.js:4451
> An error occurred executing the cmd_sendButton command: [Exception...
> "Component returned failure code: 0x80004001
> (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult:
> "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame ::
> chrome://messenger/content/messengercompose/MsgComposeCommands.js ::
> expandRecipients :: line 4451" data: no]"
>
> After disabling that check, the send button is working as expected.
> Maybe that helps you, maybe not.
> Thanks.

(In reply to :Dossy Shiobara from comment #38)
> (In reply to gergilar from comment #34)
>
> gergilar, would you be able to also test creating a new TB profile and see
> if that fixes the problem for you? You can create a new profile by starting
> TB with the "-P" command line option to bring up the Profile Manager, then
> click "Create Profile" to create a new profile. Then, just add the one mail
> account that's giving you problems, and see if you can still reproduce the
> bug?
>
> Thanks!

Hi. Yes, creating a new profile solves the problem for me.

Some extra information...
Even disabling the checking in Local Address Book, when the email was already composed you cannot send it. The only way that the send button works is adding the recipient in your local address book.

(In reply to gergilar from comment #41)
> Some extra information...
> Even disabling the checking in Local Address Book, when the email was
> already composed you cannot send it. The only way that the send button works
> is adding the recipient in your local address book.

Is this true even in the newly created profile, or only in the previously created profile?

(In reply to coxmatthew from comment #36)
> (In reply to :Dossy Shiobara from comment #27)
> > coxmatthew, would you mind trying uninstalling the Linux Mint package
> > installed version, and installing the Mozilla-provided binary, just to see
> > if there's a difference? If you can still reproduce the issue with the
> > official Mozilla binaries, that would be useful to know.
> >
> > You can download the official build here:
> >
> > https://www.mozilla.org/en-US/thunderbird/all/
> >
> > If you can still reproduce the problem, then I'll go and set up a VM here
> > with "Linux Mint 17.3 Cinnamon 64-bit (Cinnamon v 2.8.8)" and see if I can
> > reproduce the problem here, as well. Also, you said you cannot reproduce
> > the problem when using a Google/Gmail account over IMAP/SMTP, but you can
> > when using an account through DavMail IMAP/SMTP when DavMail is connected to
> > Office365? I basically want to replicate your environment so that I can
> > reproduce the problem on my own, so I just want to confirm the details.
>
> (In reply to AllUses from comment #33)
> > Using a new profile may take some while as i need to do some work in the
> > meantime.
> > However, if it works with a fresh new profile then TB 52 doesn't support
> > pre-52 profiles at least with a specific setting in it. Wonder which setting
> > this could be.
> >
> > (In reply to Jorg K (GMT+2) from comment #31)
> > > And on a new profile? Start Thunderbird with -p to create one. I'm sure it
> > > will work, so there is something in the old profile that makes it fail. We
> > > need to find that something.
>
> I am also planning on trying a new profile, but things are crazy for me at
> work too. Will update as soon as possible as I'd like to get this bug
> resolved.

I've created a new profile using just my office365 account and things seem to be working. I've not encountered the issue for the last 30 or so emails I've sent or replied to.

Note that I am still using the version of Thunderbird provided through Linux Mint's update repository, so it seems the issue is related to version 52+ reading a pre-52 profile. I will slowly start adding my additional accounts and plugins to the new profile and let everybody know if I encounter an issue or am successful.

(In reply to coxmatthew from comment #43)
> I've created a new profile using just my office365 account and things seem
> to be working. I've not encountered the issue for the last 30 or so emails
> I've sent or replied to.
>
> Note that I am still using the version of Thunderbird provided through Linux
> Mint's update repository, so it seems the issue is related to version 52+
> reading a pre-52 profile. I will slowly start adding my additional accounts
> and plugins to the new profile and let everybody know if I encounter an
> issue or am successful.

Thanks for confirming that a new profile resolves the issue for you.

If you can carefully re-add things to the new profile and if you identify a step that reintroduces the problem into your new profile, that would be extremely helpful.

Ultimately, it may be necessary to inspect the previous profile to try and identify what about it is triggering the bug, but unfortunately there are too many sensitive bits of information stored in the profile to simply ask you to submit a copy. Our best hope is that one of the TB devs runs into this problem and can diagnose the problem.

I can confirmed I have the same issue.

Steps to reproduce:

Send new email (reply) where the recipient address is NOT listed in any of local address book (including Collected Address).

This happened immediately after I upgrade from Thunderbird 45.8 to 52.2 (I skipped 52.0 & 52.1).

Actual results:

Click 'Send' button (nor pressing Ctrl+Enter) do anything.

Expected results:

I should be able to send to any email address even if the recipient is NOT listed in any of local address book.

Ok, I think I figure out how to reproduce this.

As soon as the 'ldap_2.servers.history.filename' preferences is defined (which in my case is pointing to other file name, we have the issue in such we can ONLY send email if ALL recipient are listed in one of local address books (doesn't have to be in history.mab).

So we have 2 workarounds at the moment:
1. Put a new recipient into one of your local address books. Do this if you want to keep your collected address book as different file name, but not very convenience.

2. Remove 'ldap_2.servers.history.filename' preferences. The caveats on this then the collected address book will be set to default (history.mab) AND also the location of Collected Adress in the Address Book windows always set to last, despite 'ldap_2.servers.history.position' set to something else (basically this preferences is no longer honored).

This explains why new profile works. So if you want to keep your old profile you can do one of the workaround in the above.

I really hope the developer can fix this as this cause limitation on customizing address book order and the file names.

Edoardo, many thanks for the information. ldap_2.servers.history.filename is set by default to history.mab. Instead of removing you mean resetting it, right? I tried setting my preference to history1.mab and could still send.

*** Bug 1381986 has been marked as a duplicate of this bug. ***

(In reply to :Dossy Shiobara from comment #42)
> (In reply to gergilar from comment #41)
> > Some extra information...
> > Even disabling the checking in Local Address Book, when the email was
> > already composed you cannot send it. The only way that the send button works
> > is adding the recipient in your local address book.
>
> Is this true even in the newly created profile, or only in the previously
> created profile?

Sorry for the delay in the answer. I can't reproduce this behavior in the newly created profile, this just happens in the old profile. The new one works as expected.

(In reply to Edoardo Tirtarahardja from comment #46)
> Ok, I think I figure out how to reproduce this.
>
> As soon as the 'ldap_2.servers.history.filename' preferences is defined
> (which in my case is pointing to other file name, we have the issue in such
> we can ONLY send email if ALL recipient are listed in one of local address
> books (doesn't have to be in history.mab).

Is it possible that the file that is being pointed to got corrupted somehow? If you have that preference defined and pointing to some other file, can you rename that file on disk out of the way temporarily so that TB will create a new file, and see if the problem persists?

Trying to decide whether the issue has to do with the use of that preference setting, or the specific mork db file you have it pointing to.

(In reply to Jorg K (GMT+2) from comment #47)
> Edoardo, many thanks for the information. ldap_2.servers.history.filename is
> set by default to history.mab. Instead of removing you mean resetting it,
> right? I tried setting my preference to history1.mab and could still send.

I shutdown TB and remove the line in my prefs.js. But reset it in about:config should do the same. I didn't try to change it on the fly, try to restart TB after change it and make sure you send to address that doesn't exist in any of your local address books you have.

(In reply to :Dossy Shiobara from comment #50)
> (In reply to Edoardo Tirtarahardja from comment #46)
> > Ok, I think I figure out how to reproduce this.
> >
> > As soon as the 'ldap_2.servers.history.filename' preferences is defined
> > (which in my case is pointing to other file name, we have the issue in such
> > we can ONLY send email if ALL recipient are listed in one of local address
> > books (doesn't have to be in history.mab).
>
> Is it possible that the file that is being pointed to got corrupted somehow?
> If you have that preference defined and pointing to some other file, can you
> rename that file on disk out of the way temporarily so that TB will create a
> new file, and see if the problem persists?
>
> Trying to decide whether the issue has to do with the use of that preference
> setting, or the specific mork db file you have it pointing to.

I don't think so, because I can modify that file. I actually try to set it to a brand new file 'abc.mab' (in prefs.js while TB is closed). The file is created and can't send it. As soon as I add the recipient to this new 'abc.mab' I can. The I delete the entry and can't send it again.

In my case, the original setting is 'HISTORY.MAB', I used capital letter instead of lower case. This enough to invoke the issue. Simply removing this, hence point to 'history.mab' and since I'm on Win7, the HISTORY.MAB file is still actually used (I can see the new recipient is added to it, because Windows's file name is not case sensitive) it works. So my HISTORY.MAB surely is not corrupted.

(In reply to Edoardo Tirtarahardja from comment #51)

Okay, I set a value for ldap_2.servers.history.filename = "test.mab" and couldn't reproduce the problem.

What value do you have for mail.collect_addressbook?

(In reply to Edoardo Tirtarahardja from comment #45)
> I can confirmed I have the same issue.
>
> Steps to reproduce: [...]

Edoardo, what OS/platform are you able to reproduce this on? So far we have Linux and Win7 - I'm still not able to reproduce on OSX.

I just tried to reproduce this on my Linux Mint VM (which coxmatthew indicated he experienced the bug on), using a new profile created using TB 45.8 and opened using a clean install of TB 52.2.1.

I added the line in prefs.js setting ldap_2.servers.history.filename to "test.mab" and then connecting to my Office365 account using davmail, and replying to an email that was sent from an address that is NOT in any of my address books, and the mail sent exactly as expected.

The only thing that didn't "work" is that the address didn't get added to test.mab, because "mail.collect_addressbook" wasn't set in prefs.js, so the default value of "moz-abmdbdirectory://history.mab" was used. Once I set mail.collect_addressbook to "moz-abmdbdirectory://test.mab", even the addition of the email address to the address book worked exactly as expected.

My hunch is that there is more at play here than just that one preference setting.

Well, i was stacked because i couldn't easly send emails in then last days... so i went into a more radical test.
I have removed all ldap2 settings from prefs.js and now i am able to send without any problem...
Some extra info that i am seeing now is that when composing a new email, the autocomplete when selecting a recipient doesn't work with the original prefs.js (painting recipient in red even if is valid) and it works as expected with the copied (new profile).

I am on TB 52.1.1 on Ubuntu 14.04

(In reply to gergilar from comment #55)
> Well, i was stacked because i couldn't easly send emails in then last
> days... so i went into a more radical test.
> I have removed all ldap2 settings from prefs.js and now i am able to send
> without any problem...

Could you copy and paste all the lines from prefs.js that you removed exactly as-is, assuming they don't contain any really sensitive information? Just adding the one prefs line that Edoardo identified is not sufficient for me to reproduce the problem. I'm wondering if it's a combination of settings that causes the problem.

(In reply to :Dossy Shiobara from comment #56)
> (In reply to gergilar from comment #55)
> > Well, i was stacked because i couldn't easly send emails in then last
> > days... so i went into a more radical test.
> > I have removed all ldap2 settings from prefs.js and now i am able to send
> > without any problem...
>
> Could you copy and paste all the lines from prefs.js that you removed
> exactly as-is, assuming they don't contain any really sensitive information?
> Just adding the one prefs line that Edoardo identified is not sufficient for
> me to reproduce the problem. I'm wondering if it's a combination of
> settings that causes the problem.

I have removed all this:

user_pref("ldap_2.servers.GAL.auth.dn", "");
user_pref("ldap_2.servers.GAL.auth.saslmech", "");
user_pref("ldap_2.servers.GAL.description", "GAL");
user_pref("ldap_2.servers.GAL.filename", "ldap_tst.mab");
user_pref("ldap_2.servers.GAL.maxHits", 100);
user_pref("ldap_2.servers.GAL.uri", "ldap://correos.correo.com.uy/dc=correo,%20dc=com,%20dc=uy??sub?(objectclass=*)");
user_pref("ldap_2.servers.eds.description", "EDS Address Book Bootstrapper");
user_pref("ldap_2.servers.eds.dirType", 3);
user_pref("ldap_2.servers.eds.filename", "eds.mab");
user_pref("ldap_2.servers.eds.position", 1);
user_pref("ldap_2.servers.eds.uri", "moz-abedsdirectory://");

(In reply to gergilar from comment #57)
> I have removed all this:
>
> [...]
> user_pref("ldap_2.servers.eds.description", "EDS Address Book Bootstrapper");
> user_pref("ldap_2.servers.eds.dirType", 3);
> user_pref("ldap_2.servers.eds.filename", "eds.mab");
> user_pref("ldap_2.servers.eds.position", 1);
> user_pref("ldap_2.servers.eds.uri", "moz-abedsdirectory://");

I think this is the key. Relevant information:

http://kb.mozillazine.org/Sharing_address_books#EDS
https://launchpad.net/thunderbird-eds-extension

And, this bug:

sending mail impossible in thunderbird, when plugin is installed and activated
https://bugs.launchpad.net/thunderbird-eds-extension/+bug/1326766

Do you have that add-on installed and enabled?

I can't even find a way to install this "EDS Contacts Integration" add-on any more.

Here's a post on the Mozilla blog announcing it:

https://blog.mozilla.org/labs/2011/08/introducing-evolution-contacts-integration-for-thunderbird/

That page references the project page as http://mozillalabs.com/messaging/eds-contacts-integration-for-thunderbird/ which is now a defunct (404) page.

The project page over on Launchpad seems to still exist:

https://launchpad.net/thunderbird-eds-extension

WOW!, Hehe, it looks that I have the "Messaging Menu and Unity Launcher integration". Don't know how it gets there, it was not
on purpose installed, maybe it comes with something else...
But is dissabled, and enableing it i can still send email.
Do you want me to try something else?

(In reply to gergilar from comment #60)

With TB not running, try adding back the 6 lines for the ldap_2.servers.GAL entries, then start TB and see if you can still send email.

If you can, then exit TB again, and add back the 5 lines for the ldap_2.servers.eds entries. Confirm that you cannot send email any more.

If re-adding the ldap_2.servers.eds entries causes the bug to reappear, then I'd look in your TB profile directory's "extensions" subdirectory for files starting "nsAbEDS*" - if you're on Linux, from the profile directory, you can do:

find extensions -name nsAbEDS\*

(In reply to :Dossy Shiobara from comment #54)
> ...
> The only thing that didn't "work" is that the address didn't get added to
> test.mab, because "mail.collect_addressbook" wasn't set in prefs.js, so the
> default value of "moz-abmdbdirectory://history.mab" was used. Once I set
> mail.collect_addressbook to "moz-abmdbdirectory://test.mab", even the
> addition of the email address to the address book worked exactly as expected.
>
> My hunch is that there is more at play here than just that one preference
> setting.

Yes, that's right, I do notice that the 'mail.collect_addressbook' need to be set to the same file with 'ldap_2.servers.history.filename' for adding outgoing recipient to history. Even though for there is no reason to have separate preferences to control the history file name (it just may cause confusion and potential mismatch), but in my test it doesn't really matter the value of 'mail.collect_addressbook' is set to, if the fault condition is invoked it wil. failed.

I managed to identify further settings need to be added to pref.js to reproduce fault in clean profile. You need to have an LDAP address book (at least 1, I think). Here is the minimum LDAP address book to recreate the issue ON TOP OF setting 'ldap_2.servers.history.filename' to other than 'history.mab':
user_pref("ldap_2.servers.CA-ON_QSS.auth.dn", "<snipped>");
user_pref("ldap_2.servers.CA-ON_QSS.auth.saslmech", "");
user_pref("ldap_2.servers.CA-ON_QSS.description", "QSS Global Directory");
user_pref("ldap_2.servers.CA-ON_QSS.filename", "CA-ON_QSS.MAB");
user_pref("ldap_2.servers.CA-ON_QSS.maxHits", 100);
user_pref("ldap_2.servers.CA-ON_QSS.position", 3);

NOTE: The setting 'ldap_2.servers.CA-ON_QSS.position' MUST exist (any value, doesn't matter) TOGETHER with 'ldap_2.servers.history.filename' set to other than 'history.mab' to recreate the issue. If ANY of these settings is removed, it works.

So we do have another 3rd work around:
3. Remove any 'ldap_2.servers.<LDAPabName>.position' in pref.js.

I also notice that either 'ldap_2.servers.{history|pab}.position' doesn't take effect unless the 'ldap_2.servers.{history|pab}.filename' BOTH are set to their non-default value, respectively, and you can't put LDAP AB before any of these 2.

What a nice mess. Our developer will look into it when he returns from his PTO.

(In reply to Edoardo Tirtarahardja from comment #62)
> I managed to identify further settings need to be added to pref.js to
> reproduce fault in clean profile. You need to have an LDAP address book (at
> least 1, I think). Here is the minimum LDAP address book to recreate the
> issue ON TOP OF setting 'ldap_2.servers.history.filename' to other than
> 'history.mab':
> [...]
>
> NOTE: The setting 'ldap_2.servers.CA-ON_QSS.position' MUST exist (any value,
> doesn't matter) TOGETHER with 'ldap_2.servers.history.filename' set to other
> than 'history.mab' to recreate the issue. If ANY of these settings is
> removed, it works.
>
> So we do have another 3rd work around:
> 3. Remove any 'ldap_2.servers.<LDAPabName>.position' in pref.js.
>
> I also notice that either 'ldap_2.servers.{history|pab}.position' doesn't
> take effect unless the 'ldap_2.servers.{history|pab}.filename' BOTH are set
> to their non-default value, respectively, and you can't put LDAP AB before
> any of these 2.

Excellent work, Edoardo! I can confirm that on Linux with TB 52.2.1, I can now reproduce the problem! The minimal case, with a newly created profile:

1) Define an LDAP address book.

2) Edit prefs.js to set ldap_2.servers.history.filename to something other than "history.mab".

3) Edit prefs.js to set position of that LDAP address book to a value greater than 1 (I tested position=1 and it doesn't trigger the bug).

4) Try to send an email to an address that is not found in any address book (local, collected, LDAP).

Results in the error:

NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists] MsgComposeCommands.js:4456
 expandRecipients chrome://messenger/content/messengercompose/MsgComposeCommands.js:4456:3
 GenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:2930:5
 SendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:3270:3
 defaultController.commands.cmd_sendButton.doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:700:11
 defaultController.doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:872:5
 goDoCommand chrome://global/content/globalOverlay.js:100:7
 oncommand chrome://messenger/content/messengercompose/messengercompose.xul:1:1
An error occurred executing the cmd_sendButton command: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 4456" data: no] globalOverlay.js:103
 goDoCommand chrome://global/content/globalOverlay.js:103:5
 oncommand chrome://messenger/content/messengercompose/messengercompose.xul:1:1

Jorg, looking forward to Aceman's take on the bug, now that we have very clear steps to reproduce.

*** Bug 1406911 has been marked as a duplicate of this bug. ***

Edoardo and Dossy thanks for getting the details together. (Not certain I got the summary change correct)

I experienced the same bug in Thunderbird 60.4.0 (64-bit, Ubuntu 18.04.1 LTS x86_64) yesterday. The only way how to send an email was adding the recipient in local address book.

After clicking on Send button, Thunderbird in safe mode reported 'JavaScript error: chrome://messenger/content/messengercompose/MsgComposeCommands.js, line 5656: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]'.

I had to change ldap_2.servers.history.filename' preference (history.mab file changed to new history2.mab file) as suggested by Edoardo Tirtarahardja to be able to send an email.

I have this bug with TB 60.6.1 (64-bit, Xubuntu 18.04.2 LTS)

NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]
An error occurred executing the cmd_sendButton command: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 5656" data: no]

I had to change ldap_2.servers.history.filename' preference (history.mab file changed to new history2.mab file) as suggested by Edoardo Tirtarahardja to be able to send an email.

same problem here, it has been a problem for a loong time, and only now i found this thread.

TB 71.0 (64-bit) ubuntu 18.04.2 LTS

i read the full thread and made some modification:

1) i modified ldap_2.servers.history.position from 2 to 1 and ldap_2.servers.pab.position from 1 to 2 with no success.

after that I found out that of the 3 .mab files in the profile (abook, default and history) only abook was modified in the last 4 years and tried to change all reference to that one.

I only have success after I completely replaced history.mab (and some default.mab) references with abook.mab, not exactly certain at what point but now there is only one last reference that was not abook.mab (ldap_2.servers.default.filename is still default.mab)

for now all is working ok, and I have little time to fidget even more so i keep it as it is, but if needed I could try to help more.

I am seeing this behavior now on Mac OS X Thunderbird 64-bit beta release 73.0b2

Adding a user to the local address book makes the email sendable.
Otherwise, addresses are rendered in red/orange and the "send" button does nothing in the compose window.

Never mind, this may be a different problem - cant reproduce. Will update if reproducible.

Hello gents,
latest about about this problem i was also running into today.

I updated my
Thunderbird version onto: 60.6.1 (64-bit)
Underlying OS: Ubuntu Linux
Add-On: Thunderbird Lightning (only) calendar
LDAP: Company configured link

Send button has not worked anymore after i completed my version upgrade.

Solution found:
just remove any direct LDAP connection from the email account profile/configuration

1. Go to Menu tab: Edit

2. Select: Composition

3. Disable: Any LDAP connection/entry

4. Select instead: Local Address Books

5. Save

6. Restart Thunderbird

Best regards folks / took me 2 hours to identify this issue.

Same issue with my TB, but the only workaround for me is to add the recipient to the Address Book. This has been happening for a very long time now, but I decided to research a little bit at present.
The error I see is:
```
JavaScript error: chrome://messenger/content/messengercompose/MsgComposeCommands.js, line 6156: NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]
```
OS: Gentoo Linux
TB version: 68.6.0 (from Gentoo's repository - compiled from scratch)
Add ons: Lightning and British English dictionary (error also happens without Lightning)

For reference, I tried to switch off all address books prior to looking into this bug report. I have only 2 more things to try:
1. Create a completely new profile - I will only do this when the benefits or recreating everything outweigh the overhead of creating a new entry in the address book for every new recipient (or clicking on the favourite star :) )
2. Compile with en-GB localisation for TB - this is happening now.

Ideas/questions, please let me know.

Adding to my previous comment, including en-GB localisation didn't yield any changes.

After upgrading to Thunderbird 78.1.0, the same failure started to re-surface, there are two accounts configured on my system, one for my personal email and one for my corporate email. The corporate email account is configured to auto-complete from a LDAP server, whereas the personal account is not.

Attempting to send an email with either results in the following:

```javascript
Successfully loaded OTR library libotr-5.dll from C:\Program Files (x86)\Mozilla Thunderbird\libotr-5.dll OTRLib.jsm:43:13
NetworkError when attempting to fetch resource. IgnoreLists.jsm:90:10
[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 658" data: no] L10nRegistry.jsm:658:19
[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 658" data: no] L10nRegistry.jsm:658:19
Uncaught
Exception { name: "NS_ERROR_NOT_IMPLEMENTED", message: "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]", result: 2147500033, filename: "chrome://messenger/content/messengercompose/MsgComposeCommands.js", lineNumber: 6970, columnNumber: 0, data: null, stack: "expandRecipients@chrome://messenger/content/messengercompose/MsgComposeCommands.js:6970:15\nGenericSendMessage@chrome://messenger/content/messengercompose/MsgComposeCommands.js:4365:5\nSendMessageWithCheck@chrome://messenger/content/messengercompose/MsgComposeCommands.js:4878:21\ndoCommand@chrome://messenger/content/messengercompose/MsgComposeCommands.js:994:9\ndoCommand@chrome://messenger/content/messengercompose/MsgComposeCommands.js:1157:9\ngoDoCommand@chrome://global/content/globalOverlay.js:101:18\noncommand@chrome://messenger/content/messengercompose/messengercompose.xhtml:1:12\n", location: XPCWrappedNative_NoHelper }
MsgComposeCommands.js:6970
An error occurred executing the cmd_sendWithCheck command: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgCompose.expandMailingLists]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: expandRecipients :: line 6970" data: no] globalOverlay.js:104
NS_ERROR_NOT_AVAILABLE: 2 ActivityManager.jsm:127
2020-08-13 09:19:57 gloda.collection ERROR caught exception from listener in onItemsModified: chrome://messenger/content/multimessageview.js:511: TypeError: tagsNode is null
Log4moz.jsm:766
2020-08-13 09:19:57 gloda.collection ERROR caught exception from listener in onItemsModified: chrome://messenger/content/multimessageview.js:511: TypeError: tagsNode is null

2020-08-13 09:19:57 gloda.collection ERROR caught exception from listener in onItemsModified: chrome://messenger/content/multimessageview.js:511: TypeError: tagsNode is null
Log4moz...

The workaround so far appears to *manually* add every recipient to the local address book before sending which is does not scale when dealing with mailing-lists.

Despite having disabled the LDAP directory from the global addressing preferences, the very fact that it was still in the list, albeit disabled did not allow for emails to be sent out. After completely removing it, I am now able to use: Local address books, and Automatically add outgoing e-mail addresses to my Personal Address Book. This makes TB usable again, yay!

Created attachment 9170291
Bug 1371309 - Return NS_OK instead of the last return value from a loop, which is useless information. r?BenC

Does that satisfy your need for information (since you didn't actually ask for anything in particular)?

Sure does, thanks. I don't know how much people read bug mail, I used to churn through 200 per day, this morning I had 40. So I mostly use NI to attract some attention. The implicit question always is: Hey, what do you think about this? This falls into the area of your expertise and I think it's about time we do something about it ... where "about time" may be a very short time span if it's a recent regression.

Since I have a 100% reproducible problem here with my company LDAP directory, is anyone interested in providing fixes for me try out?

A fix will be in our nightly version once it lands, which it is now ready to do.

Pushed by <email address hidden>:
https://hg.mozilla.org/comm-central/rev/2da49519942d
Return NS_OK instead of the last return value from a loop, which is useless information. r=BenC

Comment on attachment 9170291
Bug 1371309 - Return NS_OK instead of the last return value from a loop, which is useless information. r?BenC

already on beta

Comment on attachment 9170291
Bug 1371309 - Return NS_OK instead of the last return value from a loop, which is useless information. r?BenC

[Triage Comment]
Approved for esr78

Thunderbird 78.2.2:
https://hg.mozilla.org/releases/comm-esr78/rev/7d52ee217646

*** Bug 1483579 has been marked as a duplicate of this bug. ***