Bugzilla

Here's a try build for a possible fix: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=ad0bfd35368604e39c8c95369810fb6eff26fe40  It's basically what I proposed in bug 1282182. If there is no window, instead of giving up it now checks if password manager has a password stored. If it does, the password returned and used  to authenticate. If not, an empty password and an error is returned and no prompt occurs as is expected when there is no window to show it on.
Kai said in comment 2, the password is "remembered".  So with the try build when the initial windowless "EnsureExists" occurs the stored password should be obtained directly from password manager and TB  will continue on rather than just hanging.

However, I don't think this would fix the problem that Kai is seeing  if passwords were not remembered/stored and had to be entered at startup. So I still need to understand why "EnsureExists" is occurring first.

Not sure if Kai can still duplicate the bug and then test with the try build. Anyhow, maybe Kai and/or Magnus could just take a look at the associated diff and see if it looks reasonable or know a better way to address this issue.

The issue of windowless URLs failing to authenticate has come up in a couple of other contexts such as the already mentioned bug 1282182. I first became aware of it in bug 1690093 where Ben Bucksch pointed out why this line exists: https://searchfox.org/comm-central/rev/ead29136c954ba6aafe0adcf53734a54be401038/mailnews/imap/src/nsImapProtocol.cpp#8368.
Bug 1690093 was also triggered by the "EnsureExists" URL but didn't cause a failure to start up since it wasn't the first URL to occur. The fix there added a "window" to one occurrence of EnsureExists but didn't add on for where it's failing for Kai: see the 3rd parameter here https://searchfox.org/comm-central/rev/1149553854dc7cfac00639ef11fc3c79fa4d47d2/mailnews/imap/src/nsImapMailFolder.cpp#1047

Here's a try build for a possible fix: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=ad0bfd35368604e39c8c95369810fb6eff26fe40  It's basically what I proposed in bug 1282182. If there is no window, instead of giving up it now checks if password manager has a password stored. If it does, the password returned and used  to authenticate. If not, an empty password and an error is returned and no prompt occurs as is expected when there is no window to show it on.
Kai said in comment 2, the password is "remembered".  So with the try build when the initial windowless "EnsureExists" occurs the stored password should be obtained directly from password manager and TB  will continue on rather than just hanging.

However, I don't think this would fix the problem that Kai is seeing  if passwords were not remembered/stored and had to be entered at startup. So I still need to understand why "EnsureExists" is occurring first.

Not sure if Kai can still duplicate the bug and then test with the try build. Anyhow, maybe Kai and/or Magnus could just take a look at the associated diff and see if it looks reasonable or know a better way to address this issue.

The issue of windowless URLs failing to authenticate has come up in a couple of other contexts such as the already mentioned bug 1282182. I first became aware of it in bug 1690093 where Ben Bucksch pointed out why this line exists: https://searchfox.org/comm-central/rev/ead29136c954ba6aafe0adcf53734a54be401038/mailnews/imap/src/nsImapProtocol.cpp#8368.
Bug 1690093 was also triggered by the "EnsureExists" URL but didn't cause a failure to start up since it wasn't the first URL to occur. The fix there added a "window" to one occurrence of EnsureExists but didn't add a window for where it's failing for Kai: see the 3rd parameter here https://searchfox.org/comm-central/rev/1149553854dc7cfac00639ef11fc3c79fa4d47d2/mailnews/imap/src/nsImapMailFolder.cpp#1047

Here's a try build for a possible fix: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=ad0bfd35368604e39c8c95369810fb6eff26fe40  It's basically what I proposed in bug 1282182. If there is no window, instead of giving up it now checks if password manager has a password stored. If it does, the password is returned and used  to authenticate. If not, an empty password and an error is returned and no prompt occurs, as is expected when there is no window to show it on.
Kai said in comment 2, the password is "remembered".  So with the try build when the initial windowless "EnsureExists" occurs the stored password should be obtained directly from password manager and TB  will continue on rather than just hanging.

However, I don't think this would fix the problem that Kai is seeing  if passwords were not remembered/stored and had to be entered at startup. So I still need to understand why "EnsureExists" is occurring first.

Not sure if Kai can still duplicate the bug and then test with the try build. Anyhow, maybe Kai and/or Magnus could just take a look at the associated diff and see if it looks reasonable or know a better way to address this issue.

The issue of windowless URLs failing to authenticate has come up in a couple of other contexts such as the already mentioned bug 1282182. I first became aware of it in bug 1690093 where Ben Bucksch pointed out why this line exists: https://searchfox.org/comm-central/rev/ead29136c954ba6aafe0adcf53734a54be401038/mailnews/imap/src/nsImapProtocol.cpp#8368.
Bug 1690093 was also triggered by the "EnsureExists" URL but didn't cause a failure to start up since it wasn't the first URL to occur. The fix there added a "window" to one occurrence of EnsureExists but didn't add a window for where it's failing for Kai: see the 3rd parameter here https://searchfox.org/comm-central/rev/1149553854dc7cfac00639ef11fc3c79fa4d47d2/mailnews/imap/src/nsImapMailFolder.cpp#1047