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

Steps to reproduce:

This issue is reported after reporting https://github.com/Extended-Thunder/send-later/issues/338 against the "Send Later" extension.

The full reproduction case is listed in the above. Send Later's author mentioned that at least part of the issue I reported is the failur eof TB to send unsent messages when the connection to the mail server becomes available (in my case when I reconnect my company's VPN)

Actual results:

As explained in https://github.com/Extended-Thunder/send-later/issues/338, the problem happens when a scheduled mail is to be sent by Send Later extension ans the connection to the mail server is not possible (VPN down). TB properly displays a warning message but then the mail is never sent again until another "send unsent messages" is triggered by another Send Later scheduled mail.

Expected results:

From what I understand of Send Later author's suggestion, it is expected that TB gets a signal to "send unsent messages" when the mail server is reachable again.

Does problem reproduce when using newer version (91 for example) with Help > Troubleshoot mode?

Actually, it's hard to reproduce in Troubleshoot mode as this mode de-activates extensions and the only way to indeed trigger the problem to happen is when the Send Later extension.

But indeed, when NOT in troubleshoot mode, the problem still happens, I'm afraid. Whether it to be related to TB or the extension or (as suggested by Send Later author) both, is something beyond my ability to test

Rather than relying on the reference to the Send Later issue, I want to spell out in detail here what the issue is.

TB has a concept of automatically detected offline mode, and it knows to ask the user whether to send unsent messages when there are messages in the Outbox and TB transitions from offline to online.

The problem is that offline -> online trigger doesn't happen if TB is connected to the internet fine but only some of the servers it talks to are unreachable.

Specifically, if the user has an account configured in TB whose servers can only be accessed over a VPN, and the user starts up TB when the VPN isn't connected, and then connects the VPN, TB won't treat that as an offline -> online event.
I'm guessing, but do not know for certain, that this may only occur when the user has multiple accounts configured in TB and some of them are accessible without the VPN. This guess is based on the suspicion that TB's "detect when offline automatically" functionality is based on connections to mail server, and it thinks it's online if any connections are active. Just a guess, though, haven't looked at the code.
I'm not sure what the right fix is here. TB probably shouldn't run in offline mode if some servers are accessible, since that would block access to all servers.

Thinking outside the box, maybe offline vs. online is the wrong paradigm entirely for determining when to prompt the user about sending unsent messages. Maybe TB should be periodically checking not for offline vs. online, but rather for if any of the SMTP servers required to deliver messages currently in the Outbox were previously inaccessible and have suddenly become accessible, and prompt the user about sending unsent messages at that point.