Let's be constructive. * The fix for Bug 1592258 was needed, and is still needed for some users. * The fix for Bug 1592258 *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is some kind of unwanted interaction, I'd be happy to help fix it. Please describe the problem in detail, and we can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Bug 1528136 Comment 101 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Let's be constructive. * The backed out patch was needed, and is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is some kind of unwanted interaction, I'd be happy to help fix it. Please describe the problem in detail, and we can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is some kind of unwanted interaction, I'd be happy to help fix it. Please describe the problem in detail, and we can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. Please describe the problem in detail, and we can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a (realistic) problem, I'd be happy to help fix it. Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. Please describe the problem in detail, so that I can fix it. (It should be realistic, though, not artificially constructed.) Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. Please describe the problem in detail, so that I can fix it. (It should be realistic, not artificially constructed.) Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. (As long as it's not just artificially constructed.) Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. (As long as it's not just artificially constructed.) Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) None of them work with the fix here. Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. (As long as it's not just artificially constructed.) Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some soft of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. (As long as it's not just artificially constructed.) Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some sort of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. (As long as it's not just artificially constructed.) Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some sort of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, went through the account creation dialog, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. (As long as it's not just artificially constructed.) Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some sort of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, went through the account creation, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsft365 account with IMAP and MFA. Could you please why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. (As long as it's not just artificially constructed.) Please describe the problem in detail, so that I can fix it. Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some sort of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, went through the account creation, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsoft365 account with IMAP and MFA. Could you please tell why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. Please describe the problem in detail, so that I can fix it. (As long as it's not just artificially constructed.) Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some sort of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, went through the account creation, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsoft365 account with IMAP and MFA. Could you please tell why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. Please describe the problem in detail, so that I can fix it. (As long as it's not just artificially constructed.) Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some sort of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've created a new company account and domain, used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, went through the account creation, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsoft365 account with IMAP and MFA. Could you please tell why you think this fix it correct?
Let's be constructive. * The backed out patch is still needed for some users. * The backed out patch *can* inherently work with the fix here. * It uses VerifyLogin(), which is the same function that we use at the end of the account creation. The only difference is that we'd do the auth earlier. But there is nothing in the code that you backed out that is inherently incompatible with the fix here. * If there is a problem, I'd be happy to help fix it. Please describe the problem in detail, so that I can fix it. (As long as it's not just artificially constructed.) Most importantly: * The fix here in this bug does not work for me. As mentioned above, I was not able to log in with any of the Office365 test accounts that I have. (Apart from those that have IMAP enabled and MFA disabled, i.e. those accounts that worked even before this fix.) Just to ensure that the problem is not some sort of setting in my test accounts, I just created another completely new Office365 test domain and new user. I've created a new company account and a new domain, used Microsoft 365 Business Basic, changed none of the settings, and only enabled MFA for that test user. As admin, I activated MFA for that user, and as the user, I set up an TOTP app as 2 factor auth. IMAP is activated for that user. I changed nothing else, completely virgin account with MFA and IMAP. I tried to log in with Thunderbird trunk - with the fix here -, went through the account creation, IMAP is selected, and when I click [Done], I get: "Unable to log in at server. Probably wrong configuration, username or password". So, from what I see, the fix here does not work, with a standard Microsoft365 account with IMAP and MFA. Could you please tell why you think this fix it correct?