1991298 - Bug 1956258 broke default accounts added via JsAccount

Status: RESOLVED FIXED

(MailNews Core :: Account Manager, defect)

Description

[betterbird.project+18]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Edg/140.0.0.0

Steps to reproduce:

When OWL is used and the OWL account is set as default account, this is lost after restart.

Regressed by:
https://searchfox.org/comm-central/rev/04808e85d3457b3833f6187ccd5f31d476065b3f/mailnews/base/src/nsMsgAccountManager.cpp#842-851
since the add-on provided account isn't active yet during restart.

The correct solution is this minimal-invasive solution:
https://phabricator.services.mozilla.com/D257098?id=1082030

Comment 1

[Magnus Melin [:mkmelin]]

Uh, the minimal-invasive solution is already landed (and uplifted to 140) so I don't know what you propose.

Comment 2

[betterbird.project+18]

You landed a very invasive solution modifying the getter instead of only getting the default account when really required.
The suggestion is to back that out and land https://phabricator.services.mozilla.com/D257098?id=1082030 instead. Please scroll down to the end to see the code changes, essentially only:

--- a/mailnews/compose/src/nsMsgComposeService.cpp
+++ b/mailnews/compose/src/nsMsgComposeService.cpp
@@ -563,8 +563,11 @@ nsMsgComposeService::GetDefaultIdentity(
   nsCOMPtr<nsIMsgAccount> defaultAccount;
   rv = accountManager->GetDefaultAccount(getter_AddRefs(defaultAccount));
   NS_ENSURE_SUCCESS(rv, rv);
 
+  if (!defaultAccount) {
+    accountManager->AutosetDefaultAccount();
+  }
   return defaultAccount ? defaultAccount->GetDefaultIdentity(_retval) : NS_OK;
 }

Comment 4

[Hartmut Welpmann [:welpy-cw]]

Ben, is this something you can workaround in your add-on without much hassle? Otherwise I'd suggest to fix this regression, also there may be more add-ons relying on JsAccount.

Comment 5

[Ben Bucksch (:BenB)]

Not easy for us to work around, no, because by the time that Owl starts, Thunderbird has already removed the default account, and we have no way to know that we were the default account. The only way for us to work around that would be monitor the default account changes at all times, to make a separate pref where we remember that we were the default account, basically a duplicate of the Thunderbird pref, and restore the default account on every startup. There is obviously quite some potential for things to go wrong, so it's definitely not easy.

The bug is that Thunderbird takes away the default account prematurely, too early. Much easier to fix that at the core.

Thank you for considering this.

Comment 6

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 1991298 - Do not reassign default status of uninitialized accounts. r=mkmelin

Since Bug 1956258, nsMsgAccountManager::GetDefaultAccount always tries to
auto-set it if none could be found. When this function is first called during
startup, JsAccounts may not have been initialized yet, so the getter should
simply return nullptr in this case.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4e33048c9e0f
Do not reassign default status of uninitialized accounts. r=mkmelin