Bug 1528136 Comment 118 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

In general, we have 4 different user types/configurations on Office365:
1. IMAP enabled, MFA disabled
2. IMAP enabled, MFA enabled
3. IMAP disabled (with or without MFA)
4. Other custom configuration through Conditional Access policies or other uncommon settings

Status of each:
1. Was working before and is still working
2. Is supposed to be fixed in this bug, but not working yet
3. Needs Exchange protocols, and should default to them. This was working before and broke with the backout.
4. Like 3.

From my understanding, here are the remaining pro needs several fixes:
1. The code problems mentioned in the code reviews above.
2. The fix will not work at all (in the account creation) until the ISPDB entry for Office365 is changed to OAuth2. This needs to wait until TB 68 is phased out. Alternatively, the code in TB 78 could be hacked to use OAuth2 for Office365. This would depend on the backed out patch.
3. The backed out patch needs to go back in. It uses the exact same function `verifyLogin()` as is run after clicking [Done], so if this fails, then it's not due to the patch, but it's because the first OAuth2 login fails or something else is buggy in the OAuth2 code. See next point.
4. It appears that the OAuth2 process fails the first time.
5. Several people reported that they have to log in via the browser first before it works in Thunderbird. Aleca said that he explicitly checked [x] Trust this device, which made the difference.
In general, we have 4 different user types/configurations on Office365:
1. IMAP enabled, MFA disabled
2. IMAP enabled, MFA enabled
3. IMAP disabled (with or without MFA)
4. Other custom configuration through Conditional Access policies or other uncommon settings

Status of each:
1. Was working before and is still working
2. Is supposed to be fixed in this bug, but not working yet
3. Needs Exchange protocols, and should default to them. This was working before and broke with the backout.
4. Like 3.

From my understanding, here are the remaining pro needs several fixes:
1. The code problems mentioned in the code reviews above.
2. The fix will not work at all (in the account creation) until the ISPDB entry for Office365 is changed to OAuth2. This needs to wait until TB 68 is phased out. Alternatively, the code in TB 78 could be hacked to use OAuth2 for Office365. This would depend on the backed out patch.
3. The backed out patch needs to go back in. It uses the exact same function `verifyConfig()` as is run after clicking [Done], so if this fails, then it's not due to the patch, but it's because the first OAuth2 login fails or something else is buggy in the OAuth2 code. See next point.
4. It appears that the OAuth2 process fails the first time.
5. Several people reported that they have to log in via the browser first before it works in Thunderbird. Aleca said that he explicitly checked [x] Trust this device, which made the difference.
In general, we have 4 different user types/configurations on Office365:
User types:
1. IMAP enabled, MFA disabled
2. IMAP enabled, MFA enabled
3. IMAP disabled (with or without MFA)
4. Other custom configuration through Conditional Access policies or other uncommon settings

Status of each:
User types:
1. Was working before and is still working
2. Is supposed to be fixed in this bug, but not working yet
3. Needs Exchange protocols, and should default to them. This was working before and broke with the backout.
4. Like 3.

From my understanding, here are the remaining problems. They need several fixes:
Bugs:
1. The code problems mentioned in the code reviews above.
2. The fix will not work at all (in the account creation) until the ISPDB entry for Office365 is changed to OAuth2. This needs to wait until TB 68 is phased out. Alternatively, the code in TB 78 could be hacked to use OAuth2 for Office365. This would depend on the backed out patch.
3. The backed out patch needs to go back in. It uses the exact same function `verifyConfig()` as is run after clicking [Done], so if this fails, then it's not due to the patch, but it's because the first OAuth2 login fails or something else is buggy in the OAuth2 code. See next point.
4. It appears that the OAuth2 process fails the first time.
5. Several people reported that they have to log in via the browser first before it works in Thunderbird. Aleca said that he explicitly checked [x] Trust this device, which made the difference.
In general, we have 4 different user types/configurations on Office365:
User types:
1. IMAP enabled, MFA disabled
2. IMAP enabled, MFA enabled
3. IMAP disabled, with or without MFA
4. Other custom configuration through Conditional Access policies or other uncommon settings

Status of each:
User types:
1. Was working before and is still working
2. Is supposed to be fixed in this bug, but not working yet
3. Needs Exchange protocols, and should default to them. This was working before and broke with the backout.
4. Like 3.

From my understanding, here are the remaining problems. They need several fixes:
Bugs:
1. The code problems mentioned in the code reviews above.
2. The fix will not work at all (in the account creation) until the ISPDB entry for Office365 is changed to OAuth2. This needs to wait until TB 68 is phased out. Alternatively, the code in TB 78 could be hacked to use OAuth2 for Office365. This would depend on the backed out patch.
3. The backed out patch needs to go back in. It uses the exact same function `verifyConfig()` as is run after clicking [Done], so if this fails, then it's not due to the patch, but it's because the first OAuth2 login fails or something else is buggy in the OAuth2 code. See next point.
4. It appears that the OAuth2 process fails the first time.
5. Several people reported that they have to log in via the browser first before it works in Thunderbird. Aleca said that he explicitly checked [x] Trust this device, which made the difference.

Back to Bug 1528136 Comment 118