Closed Bug 2035829 Opened 6 months ago Closed 4 months ago

No way to cancel authorization attempt in FTUE Account Hub

Categories

(Thunderbird :: Account Manager, defect)

Thunderbird 153
defect

Tracking

(thunderbird153 fixed, thunderbird154 fixed)

RESOLVED FIXED
154 Branch
Tracking Status
thunderbird153 --- fixed
thunderbird154 --- fixed

People

(Reporter: jtracey, Assigned: freaktechnik)

References

(Blocks 3 open bugs)

Details

Attachments

(1 external file)

If you start the login process in account hub and get to the point where an external browser window is launched for authentication, there's no way to cancel the attempt. This means if you close the browser tab without authenticating, Thunderbird is stuck in this state until you close it, and you can't add any accounts.

I'm pretty sure I tested this exact flow myself, and I know I asked the QA team to test it when bug 2019793 landed, so I suspect this is regression from a recent change.

I think the fix is simple, since there's already an AbortController set up for this, it just needs a "Cancel" button in the UI hooked up to it. (We can't tell if the browser tab is closed, so the cancellation has to be user-controlled.)

Justin, you tested using daily v152?

Bug 2019793 was fixed v150. Maybe caused by v151 Bug 1999082 - "Exchange Auth Error" adding outlook.com in Account Hub ?

Flags: needinfo?(jtracey)

I see what happened now: I don't think it's regression, I think it's a difference in UI between the first account and additional accounts. For additional accounts, Account Hub has a way to close it. For the first account, you can only minimize it. So we just never tested cancelling with a fresh profile.

Flags: needinfo?(jtracey)
Summary: No way to cancel authorization attempt in Account Hub → No way to cancel authorization attempt in FTUE Account Hub
Version: unspecified → Thunderbird 153

The OAuth during account setup is currently not cancelable from Account Hub. We ask the protocol to verify the logons and wait until that completes: https://searchfox.org/comm-central/source/mail/components/accountcreation/modules/ConfigVerifier.sys.mjs#389. The API on the protocol uses an URI listener for feedback - probably because promises didn't exist yet, or if they did were way too annoying to use... (https://searchfox.org/comm-central/rev/515d676833676e10cbc30a5b1d9d4754e71a17bb/mailnews/base/public/nsIMsgIncomingServer.idl#266 and https://searchfox.org/comm-central/rev/515d676833676e10cbc30a5b1d9d4754e71a17bb/mailnews/compose/public/nsIMsgOutgoingServer.idl#203)
Either way, we currently can't abort the action after we started it. We could ignore it, but that would just leak a bunch of stuff.

The correct solution on the UI side is to show the back button as cancel button during the config verifier checks (assuming that is actually abortable, or at least we can abandon it safely), and only make the action uncancelable after when we actually create the account.

There is another alternative of course, where we explicitly run the OAuth from Account Hub and then store the result. However that'd mean that Account Hub has to know more about how OAuth works with email accounts that it currently doesn't need to know about.

We'll probably do a dirty fix for the short term and then consider cleaning this up later. The short term fix is to make the account hub allow cancelling during the config verifier, without propagating that cancel into the verifier. This means the OAuth request won't ever be cancelled on the TB side (and we leave the server running), but you can still go back and retry etc. Importantly the load during account creation (which happens after the verifier completed) should still not be abortable.

Assignee: nobody → martin

There is another alternative of course, where we explicitly run the OAuth from Account Hub and then store the result. However that'd mean that Account Hub has to know more about how OAuth works with email accounts that it currently doesn't need to know about.

What would it need to know? For reference, Microsoft accounts often need to authenticate while getting server information, and don't need to reauth when the actual account creation happens. That makes me think Account Hub wouldn't need to store anything, it would just need to launch the OAuth flow independently first.

(In reply to Justin Tracey [:jtracey] from comment #5)

What would it need to know? For reference, Microsoft accounts often need to authenticate while getting server information, and don't need to reauth when the actual account creation happens. That makes me think Account Hub wouldn't need to store anything, it would just need to launch the OAuth flow independently first.

It's more about separation of concerns, currently account hub doesn't know anything about how oauth credentials are requested or stored for each protocol. That's all in some other layer. The most we do is query OAuth2Providers.getHostnameDetails (apart from what exchange auto discover has to do for oauth in autodiscover, but that's mostly concerned about that and not really about setting it up for the account afterward).

And the issue is that the layer that does it currently doesn't have any cancelling/aborting features.

Status: NEW → ASSIGNED

So turns out we might not be able to only do this partially, due to the gConnecting lock preventing multiple OAuth2 flows to be active for the same provider. So while we can make the UI cancel, you still won't be able to restart that OAuth2 flow.
https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2.sys.mjs#42-47

gConnecting doesn't affect the external browser flow, and the internal browser flow can already be cancelled by closing the popup.

Blocks: 2046212

Pushed by martin@humanoids.be:
https://hg.mozilla.org/comm-central/rev/22980c30d865
Allow cancelling during config verification in account hub. r=darktrojan,klamping

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 154 Branch

Comment on attachment 9596239 [details]
Bug 2035829 - Allow cancelling during config verification in account hub. r=#thunderbird-front-end-reviewers

Uplift Approval Request

  • Please state case for uplift consideration and ensure bug severity is set: Allows getting out of a situation where the only solution is to close TB and start it again during first time setup when setting up an email account with OAuth2 through an external browser.
  • User impact if declined: Have to close and re-open Thunderbird when OAuth2 in external browser didn't connect through (tab closed before flow completed, for example) to be able to progress in the initial mail account setup.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Daily?: Yes
  • Has the fix been verified in Beta?: No
  • Needs manual test from QA?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Changes to the account config verification logic, though it should only affect the cleanup thereof.
  • Does the fix cause any migrations to be skipped?: No
  • String changes made/needed: -
Attachment #9596239 - Flags: approval-comm-beta?
Severity: -- → S2

Comment on attachment 9596239 [details]
Bug 2035829 - Allow cancelling during config verification in account hub. r=#thunderbird-front-end-reviewers

[Triage Comment]
Approved for beta

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

Attachment

General

Created:
Updated:
Size: