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

Steps to reproduce:

1. Go to "Tools" > "Account settings".
2. Click on "Account actions" > New account.
3. Fill e-mail address and password.

Actual results:

Into the "Available configurations" section, when clicking into "Exchange/Office 365" without installing Owl extension, when selection "POP3" or "IMAP", it's not possible to finish the account configuration.

Expected results:

The "Ready" blue button should be available when selecting "POP3" or "IMAP" options after selecting "Exchange/Office 365" without Owl extension installed.

Given the Exchange/Office 365 segment of the wizard absolutely requires the add-on owl to function, you are prevented from going further until it is installed.

What is not correct it the failure to re-enable the Done button when you change the selection to IMAP and POP.

So I can confirm your bug report on Windows 10.

Also includes various error handling fixes: if we try to install Owl on nightly (not compatible) it installs, but is disabled. So won't work. The "Install" button was also doing the "Done" part which it should not, as we then ended up with success messages + failure message.

Thanks for the report, the patch looks good and fixes the problems.
There's another issue which I'm not sure if it's by design:

• Write an outlook/office365 account
• Select Exchange/Office365 and Install OWL.
• After successful installation, select IMAP or POP3.

Result:
The Exchange/Office365 disappears and it can't be selected anymore.

It does that because on install it changes the config account type from "exchange" (which is a family of types) to the internal add-on type (e.g. "owl") which is an unrecognized type and therefor filtered out. I'll fix it.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/3dc97d2501c7
account wizard should make sure to enable "Done" button when selecting back to a standard protocol (from exchange). r=aleca

Comment on attachment 9246647 [details]
Bug 1729965 - account wizard should make sure to enable "Done" button when selecting back to a standard protocol (from exchange). r=aleca

[Approval Request Comment]
Regression caused by (bug #): bug 1697575
User impact if declined: can't select IMAP/POP if selected Exchange first
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): fairly safe, but account setup has many different variations to take into account

Comment on attachment 9246647 [details]
Bug 1729965 - account wizard should make sure to enable "Done" button when selecting back to a standard protocol (from exchange). r=aleca

[Triage Comment]
Approved for beta

Thunderbird 94.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/041d4e65bc44

not yet on beta, so let's pass on this for 91.3.0

This patch (attachment 9246647 [details], already landed) is completely borked. I've tested it, and it works without this patch and breaks with this patch. It breaks the installation in 100% of the cases. See Phab D128882 for code details.

The patch needs to be backed out. I can make a new, more minimal fix.

Ensure that the [Done] button is enabled after switching protocols.

Catch errors from validateAndFinish() function and show them.

Not strictly necessary to fix the bug, but ensures that errors of that function are shown to the user and we're not failing silently.

The above patches assume that the previous borked patch was backed out first. There were a number of things going wrong with it, luckily all in the superfluous changes.

ESR91 combined fix.
With this, it works like it should - https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=6bdde0a6c74d68989dba09ce83210a9a1fe75fdd

With the patch as landed, there are a number of problems. All of the problems are in parts of the patch which were irrelevant to the original bug here.

• The disabled check did not work, due to a faulty condition, and always disables the [Install] button. As landed, there is no situation where the [Install] button works, ever.
• Disabling the [Install] button in case of a disabled addon is ill-advised, for obvious reasons: The user has no way to install the latest updated addon (which may now be compatible). In fact, the installation mght be the one way to fix the problem, but this change disables the [Install] button.
• Before, we deliberately set up the account immediately after the installation. With this patch as landed, the user is now required to make an extra click on [Done]. This is a UX change, which does not belong into such a bugfix here, and which has absolutely nothing to do with the bug here. This alone means that it should not have been included in this patch.
• Before, we were catching exceptions in the onCreate() UI handler. With the change, any possible exceptions (that specifically includes programming bugs) are not caught and end up only on the error console, and we fail silently. That's bad. In general, all event handlers must have a top-level try/catch block and show the error in a meaningful way. Assuming that there will never be bugs is unrealistic, and having things fail silently is bad.

None of these changes were necessary or even relevant to the bug here. I consider all 4 of them to be regressions.

To make matters worse, it makes the installation impossible in some situations, and breaks things for end users. That is true even with Magnus' latest patch, which fix only the first point, and none of the others.

The patch as landed breaks stuff, so by the tree rules, it should be backed out. I have attached 2 clean patches, which fix only the actual bugs here.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/513257e75802
account config: isDisabled should return false if addon is not installed. r=aleca

Comment on attachment 9249735 [details]
Bug 1729965 - account config: isDisabled should return false if addon is not installed. r=aleca!

[Approval Request Comment]
User impact if declined: could not install Owl/Exquilla (on beta). Not that you could anyway, since it's not available there yet. But, would be a problem in 91.
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): It's well understood.

Comment on attachment 9249735 [details]
Bug 1729965 - account config: isDisabled should return false if addon is not installed. r=aleca!

[Triage Comment]
Approved for beta (only been on nightly half a day, but should be safe - hope I don't regret saying that)

[Approval Request Comment]
Regression caused by (bug #): bug 1697575
User impact if declined: can't select IMAP/POP after once clicking Exchange
Testing completed (on c-c, etc.): c-c, beta, and I manually tested the 91 try build
Risk to taking this patch (and alternatives if risky): it's well understood, but always good to test this case manually

Successful try: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=bd4c04ca2f1207259a893fdbae9e1289369f991f

Actually, the second patch didn't go into beta yet it seems

Comment on attachment 9252475 [details] [diff] [review]
Bug_1729965____esr91_version__combined_patches__account_wizard_should_make_sure_to_enable__Done__button_when_selecting_back_to_a_standard_protocol__from_exchange___r_aleca.diff

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

Actually, the second patch didn't go into beta yet it seems

[Triage Comment]
Approved for esr91, assuming the missing patch gets into this Monday's beta

Thunderbird 95.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/98c95ee1ce8f

Thunderbird 91.4.0:
https://hg.mozilla.org/releases/comm-esr91/rev/b4f354738647