+++ This bug was initially created as a clone of Bug #1666885 +++

Wearing my UX hat, here's another highly confusing and error-prone account settings focus fail, most likely regressed by bug 1610445 where we moved account settings into a tab. When the user directly opens the account settings for a specific account, he will end up in the account settings of a random unrelated account if account settings tab was still open on that other account. Which is error-prone because if I trust TB to take me to the right place, I might edit settings of another account without realizing. Shouldn't be too hard to fix.

STR

1. have several accounts A1, A2, A3
2. open account settings for A3 (sic!), and optionally a subsection or setting therein
3. a) Right-click on A1 in folder list > Settings, or
   b) Select A1 in folder list to get Account central, then choose Account settings (which is clearly visually associated with A1)

Actual result

A3 (or its subsection, but not an actual setting therein) appear to be focused in the account list of account settings (in reality, due to bug 1666885, actionable keyboard focus remains in 3-pane's folder list).

Expected result

A1 account in accounts list of account settings should have focus.

Obviously, this can be very annoying and confusing for enterprise environments with multiple accounts, and for Thunderbird testing environments. Instead of having the right account focused as the main UI suggests, they'll always have to verify and navigate around to find the right account in account settings.

Enterprise users basically never have more than one (sanctioned) account.

(In reply to Magnus Melin [:mkmelin] from comment #2)

Enterprise users basically never have more than one (sanctioned) account.

Do we have data for that??

How would one collect such data? But it's pretty clear companies in general, at least the ones that are not tiny, have no desire for their staff to use other services than their own. Why would they? It's often directly against their interests. Each user has one login, and many times it can be absolutely forbidden to connect to outside services that are not under corporate control (e.g. may not run through corp antivirus, or whatever).

I think Kai (ni - fyi) will agree that fixing this bug to provide correct access to account settings is quite crucial for avoiding even more OpenPGP support requests or erroneous bug reports. Users explicitly going into Settings of account A (directly from its primary UI) and ending up in Settings of account B instead, just because that happened to be still open, is a recipe for more confusion, wrong setups, and false bugs.

(In reply to Magnus Melin [:mkmelin] from comment #6)

How would one collect such data?

That wouldn't be easy indeed.

But it's pretty clear companies in general, at least the ones that are not tiny, have no desire for their staff to use other services than their own. Why would they? It's often directly against their interests. Each user has one login, and many times it can be absolutely forbidden to connect to outside services that are not under corporate control (e.g. may not run through corp antivirus, or whatever).

I hear you, there'll certainly be a lot of single-account corporate users out there. Nevertheless, I think even when using only company email addresses, there's nothing which stops even regular employees being given access to more than one company email address on purpose.

• For example, support staff at somecorp may have support@somecorp.example.com and john.doe@somecorp.example.com, depending on in which role and to whom they are communicating. I've seen such arrangements all over.
• Also, secretaries, group managers, seniors, bosses may all have more than one email address to look into.
• I think there's absolutely nothing special or unusual about having more than one email address in business contexts, more so for medium or self-employed business. We've had real users recently mentioning exactly that.

Be that as it may, we haven't talked about millions of our private users yet, who may surely have more than one email address to configure.
So I just think we should fix this bug, especially the false-focus parts where keyboard focus isn't even on the foreground tab, and worse, it's stuck and actionable on the background tab, as seen in my screencast of attachment 9177466 [details] (and not yet fixed, see comment 0 here). I understand that our internal pseudo-tab design isn't helpful, but we shouldn't use implementation-level as an excuse...

Maybe around here: https://searchfox.org/comm-central/rev/a41e036c6742601037e926b21612c62f1eece749/mailnews/base/prefs/content/accountUtils.js#312,318

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/5ca66da6e4f9
Fix opening per-account settings from context menu or account central may show the wrong account if account settings tab was already open. r=mkmelin

Comment on attachment 9182467 [details] [diff] [review]
Bug-1668502_account-settings-wrong-account-0.patch

[Approval Request Comment]
Regression caused by (bug #): bug 1610445
User impact if declined: account context menu can open the wrong account
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): small contained patch, not risky

Comment on attachment 9182467 [details] [diff] [review]
Bug-1668502_account-settings-wrong-account-0.patch

[Triage Comment]
Approved for beta

Thunderbird 83.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/c7b0d7c62e6b

Looks good to me in testing the 83.0b2 release candidate on Windows 10.

Comment on attachment 9182467 [details] [diff] [review]
Bug-1668502_account-settings-wrong-account-0.patch

[Triage Comment]
Approved for esr78

Thunderbird 78.4.1:
https://hg.mozilla.org/releases/comm-esr78/rev/1121edb66600

Also looks good to me in testing the 78.4.1 release candidate on Windows 10.

Weird - still reliably fails for me on 78.5.0 (32-Bit) DE with an inherited profile.

I'm sure it was also failing on 78.5.0 (64-bit) EN with a newish profile, but after I changed account names to replace the contained email addresses with descriptive names, it's now suddenly working there.