Closed Bug 1644032 Opened 4 years ago Closed 4 years ago

wrong accountId if X-Account-Key inside header

Categories

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

defect

Tracking

(thunderbird_esr78 fixed, thunderbird84 fixed)

RESOLVED FIXED
85 Branch
Tracking Status
thunderbird_esr78 --- fixed
thunderbird84 --- fixed

People

(Reporter: lieser2, Assigned: TbSync)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  1. Create an email (as eml file) that contains the X-Account-Key: account40 header
  2. Add this email to e.g. the local folder
  3. Get the message via WebExtension: message = browser.messages.get(id)
  4. Get the account ID for the message with accountId = message.folder.accountId

Actual results:

accountId is account40 instead of the correct value.

Expected results:

accountId should reflect the folder/account the message is actually in, not what is inside the X-Account-Key header in the mail.

I cannot reproduce this with TB78.5.0. The add-on I was using for my test is attached.

I moved an email from TB to my desktop, changed the id of that email and added the extra header and then added it back to Thunderbird. It did not return account40 but account1.

The add-on ads a message_display_action button and it will log the accountId and the raw email of the currently selected/displayed message to the console.

Can you confirm?

Did some testing with your add-on, and it looks like only the "Lokal Folder" account is affected.

A POP account is also affected by this. Only the IMAP account I tested with is unaffected.

Confirmed on TB78 and current Daily.

Assignee: nobody → john
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

The reason is in this code:
https://searchfox.org/comm-central/rev/7e8d6a200456b336bdc593c4bfc699ad077019ea/mail/components/extensions/parent/ext-mail.js#1514-1518

function convertFolder(folder, accountId) {
  if (!folder) {
    return null;
  }
  if (!accountId) {
    let server = folder.server;
    let account = MailServices.accounts.FindAccountForServer(server);
    accountId = account.key;
  }

For IMAP accounts the incomming accountId (which is msgHdr.accountKey) is always an empty string, regardless of the X-Account-Key header being defined or not. The final accountId will be retrieved by MailServices.accounts.FindAccountForServer.

For POP and LocalFolder folders, the incomming accountId is the value of the X-Account-Key header. MailServices.accounts.FindAccountForServer returns the correct accountId for these folders as well.

How to fix this?
Make the current fallback the default and use the incomming accountId as fallback?
Ignore the accountId from msgHdr.accountKey altogether and return null if FindAccountForServer fails?

Flags: needinfo?(geoff)

That's frustrating. The accountId argument is an optimisation, because FindAccountForServer is expensive and this function tends to be called many times at once (e.g. when getting 100 messages from a message list, it's called 100 times). But as you say, on IMAP it doesn't even work as intended so the expensive part is running anyway.

Let's just remove the accountId argument and run FindAccountForServer in all cases.

Flags: needinfo?(geoff)

Understood. I propose and did the following in the attached patch:

Looking at the code and possible performance issues, I did not remove accountId from convertFolder() but just no longer pass in the not helping msgHdr.accountKey. The FolderManager.convert() function can still accept an accountId, if that information is already available.

Furthermore, I noticed, that traverseSubfolders() is not accepting an accountId at all, even though subfolders should be from the same account and thus we do not need to rerun the expensive lookup. The method browser.accounts.list() is actually passing in the correct accountId.
https://searchfox.org/comm-central/rev/f8c11a36225bbe5e145f1a9a0a3801428e265715/mail/components/extensions/parent/ext-accounts.js#25

I therefore changed traverseSubfolders() to accept an accountId.

Attachment #9189722 - Flags: review?(geoff)
Comment on attachment 9189722 [details] [diff] [review]
bug1644032_fix_accountId_in_folders_accounts_api.patch

Review of attachment 9189722 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch. We're already calling traverseSubfolders with a second argument in ext-accounts.js.
Attachment #9189722 - Flags: review?(geoff) → review+

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/508b9ca35fac
Ignore accountId from message headers when converting folders for WebExt APIs. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

I added some comments to try to avoid making the same mistake again.

Target Milestone: --- → 85 Branch

Comment on attachment 9189722 [details] [diff] [review]
bug1644032_fix_accountId_in_folders_accounts_api.patch

[Approval Request Comment]
User impact if declined:
WebExtension API remains broken

Testing completed (on c-c, etc.):
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=deb52d0847ca3f7a77eac2bf61bf986f2d3f637a

Risk to taking this patch (and alternatives if risky):
I hope none.

Attachment #9189722 - Flags: approval-comm-esr78?
Attachment #9189722 - Flags: approval-comm-beta?

Comment on attachment 9189722 [details] [diff] [review]
bug1644032_fix_accountId_in_folders_accounts_api.patch

[Triage Comment]
Approved for beta

Attachment #9189722 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9189722 [details] [diff] [review]
bug1644032_fix_accountId_in_folders_accounts_api.patch

[Triage Comment]
Approved for esr78

Attachment #9189722 - Flags: approval-comm-esr78? → approval-comm-esr78+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: