1743287 - browser.accounts.getDefault can return null if a user has no default account

Status: RESOLVED INVALID

(Thunderbird :: Add-Ons: Extensions API, defect)

Description

[Mark Banner (:standard8)]

I've seen before that users can sometimes not have default accounts for some reason.

I've just had a case where this was happening for a user.

The code was trying to do:

        let defaultAccount = await browser.accounts.getDefault();
        let identityDetail = await browser.identities.getDefault(
          defaultAccount.id
        );

but failing with Uncaught (in promise) TypeError: defaultAccount is null

We should probably handle this case as it seems to be an error in Thunderbird's settings - re-setting an account as default fixes it, but Thunderbird should have had a default account anyway.

The other option (and maybe better one) is to get the core account handling to reset the default if there isn't one already.

Comment 1

[John Bieling (:TbSync)]

We did fix bug 1680653, where a removed / non-existing account could remain as default, which might lead to a null return value. Other than that, I do not know how a profile could end in a state, where no default account is defined.

Edit: I deleted all accounts (which makes getDefault() return null) and then I create a new one which was automatically set as default.

The WebExtension API states that it could return null if no default account is defined, and the concept in core is also to return null if no default account is defined. So I am not sure the API should do something about this (what account should it pick as default?)

I suggest moving this to the core component.

Comment 2

[John Bieling (:TbSync)]

What could be done is to call nsMsgAccountManager::AutosetDefaultAccount() when nsMsgAccountManager::GetDefaultAccount fails to find a default account. But I am not an expert there. Magnus?

However, this will still not fix your issue in all cases (for example, if no account is defined or if none can be set at default). I think you have to check the return value of browser.accounts.getDefault() in any case, as stated in the documentation.

Comment 3

[Magnus Melin [:mkmelin]]

(In reply to John Bieling (:TbSync) from comment #2)

What could be done is to call nsMsgAccountManager::AutosetDefaultAccount() when nsMsgAccountManager::GetDefaultAccount fails to find a default account. But I am not an expert there. Magnus?

Sounds reasonable yes.

Comment 4

[John Bieling (:TbSync)]

I am not feeling comfortable making this change. Having a getter that is potentially changing the default (from null) feels wrong. As pointed out before, this is not fixing the reported issue. The developer still has to check for null even after this change has been done.

I am going to declare this as invalid, as the observed behaviour is in line with the documentation of the WebExt API.

Please file a bug for the core component, if you think nsMsgAccountManager::GetDefaultAccount() should call nsMsgAccountManager::AutosetDefaultAccount().