Open Bug 1622181 Opened 3 years ago Updated 5 months ago

Add 'Existing Email Account' does not have OAuth2 when configuring an account manually

Categories

(Thunderbird :: Account Manager, defect)

x86_64
All
defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: raysatiro, Assigned: david.ward)

References

()

Details

Attachments

(9 files, 2 obsolete files)

Attached image Capture.PNG

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

Steps to reproduce:

I added a gmail account in Thunderbird 68.4.2 (32-bit) several days ago using the 'Existing Email Account' UI and OAuth2 was not listed as an option.

Actual results:

See above.

Expected results:

OAuth2 should be listed as an option when adding an existing e-mail account.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → S3

The severity of these bugs was changed, mistakenly, from normal to S3.

Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.

Severity: S3 → --

I can confirm that OAuth2 isn't a selection when manually configuring a gmail address using 68.7.0 on Ubuntu 18.04.4 LTS Linux, or 77.0b3 or 78.0a1.

Status: UNCONFIRMED → NEW
Component: Untriaged → Account Manager
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → x86_64
Summary: Add 'Existing Email Account' does not have OAuth2 → Add 'Existing Email Account' does not have OAuth2 when configuring an account manually

The SMTP server may have been configured using dynamic OAuth2 settings for an
otherwise unknown hostname. For now, simply make the behavior consistent with
editing incoming server settings, where the OAuth2 menu item is never hidden.

Depends on D98012

Assignee: nobody → david.ward
Status: NEW → ASSIGNED
Attachment #9189860 - Attachment description: Bug 1622181 - Part 4: Show OAuth2 option during manual config whenever hostname is known. → Bug 1622181 - Part 4: Do not hide OAuth2 option during manual config.
Attachment #9189859 - Attachment description: Bug 1622181 - Part 3: Do not apply OAuth2 settings before manual config is complete. → Bug 1622181 - Part 3: Do not hide OAuth2 option during manual config.
Attachment #9189860 - Attachment description: Bug 1622181 - Part 4: Do not hide OAuth2 option during manual config. → Bug 1622181 - Part 4: Test correctly for OAuth2 settings when guessing config.

Comment on attachment 9189858 [details]
Bug 1622181 - Part 1: Test correctly for OAuth2 settings during backend account creation.

This code change is wrong. If the user selects another auth method, or autoconfig found another auth method, that choice would be completely ignored and we'd use OAuth2 contrary to choices that were made.

createInBackend() doesn't implement policy. Rather, it saves what was specified elsewhere. This would be like a spelling correction after you press Save in Word.

Attachment #9189858 - Flags: review-

(In reply to Ben Bucksch (:BenB) from comment #11)

Comment on attachment 9189858 [details]
Bug 1622181 - Part 2: Test correctly for OAuth2 settings during backend account creation.

This code change is wrong. If the user selects another auth method, or autoconfig found another auth method, that choice would be completely ignored and we'd use OAuth2 contrary to choices that were made.

Please take a closer look. This change has no effect on the auth method that is selected, now or later.

This prevents a crash from occurring when trying to store preferences from values that haven't been set (and which shouldn't be set if OAuth2 isn't selected). These preferences are only used if OAuth2 is the selected auth method, and otherwise they are ignored.

auth method

(Answered in Phab.)

This prevents a crash

Can you fix the crash instead, please?

(In reply to Ben Bucksch (:BenB) from comment #13)

This prevents a crash

Can you fix the crash instead, please?

Please see the commit description. This is the only place to avoid it.

Attachment #9189857 - Attachment description: Bug 1622181 - Part 1: Simplify logging in verifyConfig() and verifyLogin(). → Bug 1622181 - Part 1: Improve logging in verifyConfig() and verifyLogin().
Attachment #9189857 - Flags: review+
Attachment #9189858 - Flags: review-
Attachment #9189860 - Flags: review+

Comment on attachment 9189857 [details]
Bug 1622181 - Part 1: Improve logging in verifyConfig() and verifyLogin().

Revision D98009 was moved to bug 1681002. Setting attachment 9189857 [details] to obsolete.

Attachment #9189857 - Attachment is obsolete: true
Attachment #9189858 - Attachment description: Bug 1622181 - Part 2: Test correctly for OAuth2 settings during backend account creation. → Bug 1622181 - Part 1: Test correctly for OAuth2 settings during backend account creation.
Attachment #9189859 - Attachment description: Bug 1622181 - Part 3: Do not hide OAuth2 option during manual config. → Bug 1622181 - Part 2: Enable OAuth2 menu item in manual edit mode when supported.
Attachment #9189860 - Attachment description: Bug 1622181 - Part 4: Test correctly for OAuth2 settings when guessing config. → Bug 1622181 - Part 3: Test correctly for OAuth2 settings when guessing config.
Attachment #9189861 - Attachment description: Bug 1622181 - Part 5: Do not hide OAuth2 option when editing SMTP server settings. → Bug 1622181 - Part 4: Enable OAuth2 menu item in SMTP server settings when supported.

Can you fix the crash instead, please?

For the record: David wasn't talking about a crash, but a JS exception.

This is the only place to avoid it.

Actually, it isn't. This is an invalid state that was introduced by your other patch D98011. That means the other patch D98011 was buggy. See https://phabricator.services.mozilla.com/D98010 .

Duplicate of this bug: 1734449

Increasing support requests about this as well.

Do we need a SUMO kb article?

Duplicate of this bug: 1742304

This is WFM, oauth is offered immediately after switching from auto to manual config - I tested both 91.8.0 and nightly.
Do you agree? Because of bug 1757713?

Flags: needinfo?(leftmostcat)

(In reply to Wayne Mery (:wsmwk) from comment #20)

Created attachment 9270618 [details]
gmail oauth nightly manual config

This is WFM, oauth is offered immediately after switching from auto to manual config - I tested both 91.8.0 and nightly.
Do you agree? Because of bug 1757713?

I tried today to configure Gmail account in other domain than gmail.com domain name in Thunderbird 91.8.0 and there was no option OAuth2 in manual settings account configuration to choose from.

Based on the original screenshot, it looks like the reporter attempted an invalid configuration. (Note that the hostnames are ".gmail.com", not "imap.gmail.com" and "smtp.gmail.com".) Based on that, I'd be tempted to mark this as invalid, but it's unclear whether the patches listed here are intended to address this bug by creating a more robust/less provider-specific OAuth2 implementation. That may be worth breaking into a separate ticket.

Flags: needinfo?(leftmostcat)

Based on the original screenshot, it looks like the reporter attempted an invalid configuration.

OAuth2 still isn't an option for me in 91.9.0. Try manually configuring a new account test@gmail.com. A screenshot of what I see when I do that is attached.

This is what the settings should be and are when I attempt a manual configuration.

You need the full hostname and port numbers.

You need the full hostname and port numbers.

You mean the port number and subdomain are automatically filled in for you? They aren't for me. Even if I add them, it makes no difference:

Oops I captured the wrong dropdown in the previous reply. This reply should have a screenshot of the right dropdown.

Attachment #9275619 - Attachment is obsolete: true

(In reply to Ray Satiro from comment #25)

Created attachment 9275619 [details]
Thunderbird 91.9.0 missing OAuth2 in new account - second try

You need the full hostname and port numbers.

You mean the port number and subdomain are automatically filled in for you? They aren't for me. Even if I add them, it makes no difference:

The whole account is set up for me if I use the account setup wizard, enter my full name and email address, then click Continue.

I tested with a fresh profile using 91.9.0, and the Account Setup wizard tab opens in the window.

  • Entered my full name
  • Entered my email address and left the password field empty
  • After entering the email address, I clicked Configure manually
  • I did get the result that you posted in comment 23
  • Edited the Hostname fields
  • Entered the correct Port numbers, and Connection security settings.
  • The Authentication method list did not show OAuth2 as a choice
  • Clicked the `Re-test' button and "Normal Password" appeared as the Authentication method
  • Checked the drop-down list and "OAuth2" was there for each server
  • Selected it and finished creating the account

Ok thanks for the detail. IMO it's a bug that OAuth2 does not initially show as a choice. I wouldn't have thought to do that.

(In reply to Ray Satiro from comment #28)

Ok thanks for the detail. IMO it's a bug that OAuth2 does not initially show as a choice. I wouldn't have thought to do that.

Agree it's a bug, but I would use the Account Setup tab and not use Manual configuration for an existing account, unless it wasn't auto discovered.

What WaltS said.

You need to log in before you can comment on or make changes to this bug.