Open Bug 678947 Opened 11 years ago Updated 7 months ago
TB relies on its (network) online status being correct [meta]
Thunderbird has a fundamental concept of whether its online or offline, and various behaviors depend on this. In an increasing number of circumstances this status is deceptive, typically two sets of circumstances: 1: when a laptop is connected to a wireless network, but NOT to the internet - for example in a cafe where the provider is waiting to click through the T&C page 2: where the net is intermittent - for example in a heavily loaded cafe/airport, or in a less developed country. I've posted this meta-bug (not sure if that is the right term) as a place to address the general issue of dependence on online/offline status.
See: Bug #678949: Error Sending Drafts when TB thinks online, but network down Bug #675868: Tag weirdness in Imap when offline or on poor connection
(set up as meta)
Hi Mitra. This a great area in which to be seeking improvement. And a meta bug might be useful. Note however, there might be bugs which already covers what you want to accomplish to some degree (or perhaps entirely). Could you check them out and recommend a way forward? And perhaps also some discussion is needed tb-planning. No doubt improvements are needed both in front end and backend - which may include "Core" bugs which I haven't attempted to research for this comment The bugs which most stand out for me in this area are the following (in no particular order): Bug 601566 - Automatic offline management eratic and does not work Bug 468006 - online/offline experience is confusing a starter query (if imperfect): https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring&list_id=2169599&short_desc=offline%20online&field0-0-0=bug_id&type0-0-1=substring&field0-0-1=keywords&type1-0-1=allwordssubstr&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&short_desc_type=anywordssubstr&longdesc=network%20connection%20wireless&type0-0-0=nowordssubstr&value0-0-0=309719%20%09%20131578%20278403%20396328%20248742%20530193%20536737%20425723%20567716%20%20248742%20530193%20536737%20425723%20567716%20617091%20248742%20530193%20536737%20425723%20567716%20617091%20558387%20332169%20673370%20332169%20673370%20597907%20254132%20534539%20254132%20534539%20632791%20498274%20520437%20587528%20498274%20520437%20587528%20546932%20&field1-0-0=short_desc&longdesc_type=anywordssubstr&product=MailNews%20Core&product=Thunderbird&field1-0-1=short_desc
I don't see these as the same bug ... though they are relevant to the discussion. There seem to be at least three issues for me. 1: Erroneous detection of online-offline with two key sub-cases: a) intermittent/overloaded network e.g. in a cafe or airport b) a partial connection - eg. I'm connected to wireless, but its not connected to net. c) policy driven connection - I'm connected to network , but its waiting for a password/login before allowing connections like IMAP/POP. (this may be same as 1b). d) just getting it wrong, as reported in Bug #601566 - maybe same as 1a. 2: UI issues, especially a) inability to disable this check - so that you can force it to a particular state. 3: Bad behavior if the state is innacurate, e.g. as reported in Bug #678949 I haven't gone through and categorised all the bugs suggested because most seem to complain about some combination of 1, 2 and 3 above.
A major change just landed on trunk - Bug 939318 - NetworkLinkService should be enabled so Necko can respond to network changes (not offline auto-detection) This backend stuff feeds what happens or what is possible with offline auto-detection, and affects related issues - DNS, proxy, etc Related blog post http://daniel.haxx.se/blog/2014/09/26/changing-networks-with-firefox-running/
Many of the bugs named aren't just about how clever Network auto-detect is happening, they are about TB assuming that it correctly knows the status of the network and responding well to things that fail. For example ... you could be in a busy Starbucks, connectivity is there, network is up, but a lot of requests to IMAP failing.
And to extend the issue to a more general meta-issue in the UI legacy Thunderbird carries around it's neck that significantly impacts productivity (mine for sure, and from the many complaints one finds if one searches for "thunderbird modal dialogs"), the use of modal dialogs at all, for almost any reason, was deprecated when I started working at Apple in 1990: then it was still a hot topic and work was active in eradicating the remaining modal dialogs like the productivity monsters that they are. There's a great blog post about this at at http://jonoscript.wordpress.com/2011/12/07/dear-thunderbird-i-know-you-cant-save-my-draft-please-stop-complaining-about-it/ that explains the term "modal monologue." There are many bugs filed about the various modal dialogs that come up, many plague those of us that try to check our mail over fairly **** connections that typical developers probably never see. Some of these have been, frustratingly, closed as "will not be fixed." While I understand TB isn't on the most aggressive development trajectory possible, fixing these amazingly disruptive annoyances would be a huge improvement. The general solution is to move all notifications to a notification pane or the footer and completely eradicate all modal dialogs forever. A good start would be to identify any "modal monologues" and simply suppress them. They are all irrelevant and useless to anyone not actively attempting to debug a connection and are very disruptive to anyone merely trying to use the program. Optimally, thunderbird should silently retry any failure later. If a few dozen mail sync attempts fail, that might be worthy of the user's attention in some way. If a dialog box is the only way, that's fine, but it should not be modal and the working accounts should continue to do their business. Further, no dialog should ever steal focus.
Summary: TB relies on its online status being correct [meta] → TB relies on its (network) online status being correct [meta]
You need to log in before you can comment on or make changes to this bug.