The difference in behavior happens here: https://searchfox.org/comm-central/rev/c919ceff4b319030e3f7b8e76701235dbcb87c6b/mailnews/imap/src/nsImapIncomingServer.cpp#424-458 If we start Thunderbird without network connection and then request to stream a non-synced imap-message, `aProtocol` is falsy and we get into the else statement and there `(!m_skipRetryQueued)` is false as well and we end up in the else there as well. Then nothing happens anymore. None of the consumer callback functions are called. Even if we re-enable network, `aProtocol` remains falsy and we will always end up in thid dead end. If we start Thunderbird with an active network connection, disable network after startup has fininished and then try to stream a non-synced imap-message, `aProtocol` is not falsy and a real connection attempt is made.
Bug 1854586 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The difference in behavior happens here: https://searchfox.org/comm-central/rev/c919ceff4b319030e3f7b8e76701235dbcb87c6b/mailnews/imap/src/nsImapIncomingServer.cpp#424-458 If we start Thunderbird without network connection and then request to stream a non-synced imap-message, `aProtocol` is falsy and we get into the else statement and there `(!m_skipRetryQueued)` is false as well and we end up in the else there as well. Then nothing happens anymore. None of the consumer callback functions are called. Even if we re-enable network, `aProtocol` remains falsy and we will always end up in this dead end. If we start Thunderbird with an active network connection, disable network after startup has fininished and then try to stream a non-synced imap-message, `aProtocol` is not falsy and a real connection attempt is made.