359134 - Integrate with necko's automatic online/offline management

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Scott MacGregor]

Bug 312793 and Bug 76111 have given the mozilla platform the ability to automatically detect when the computer has lost it's network connectivity on Windows and Linux.

We should take advantage of this information from within Thunderbird.

I think we want the following behaviors:

1) If we detect that connectivity is gone, silently switch to offline mode until connectivity is restored. 

2) if the user chooses to go offline, do the usual prompt for offline status, and then go offline. Disable automatic offline/online management in necko while we are in user offline mode. 

3) If the user chooses to go back online, do the usual stuff for sending unsent mail, downloading new mail, etc. and then turn automatic offline/online management back online. 

4) If the automatic offline/online management puts us back in online mode because connectivity has automatically been restored, what do we do here? Do we prompt about sending unsent mail or do we silently just go online again? I'm not sure here...

Comment 1

[Scott MacGregor]

By the way, in case it isn't obvious, implementing this means no more annoying alert messages about being unable to connect to your mail server because your connectivity has gone down. We'll just be in offline mode automatically!

Comment 2

[David :Bienvenu]

> If the automatic offline/online management puts us back in online mode
>because connectivity has automatically been restored, what do we do here? Do we
>prompt about sending unsent mail or do we silently just go online again? I'm
>not sure here...

My inclination is no - if we're having up and down connections, that could be annoying. People find that prompt annoying...And we do prompt to send unsent messages the next time you startup...but I could be convinced to try it. 

Comment 3

[Scott MacGregor]

My inclination is to not do anything either when automatically going back online.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> My inclination is to not do anything either when automatically going back 
> online.

If someone is composing a message and the system goes offline on them, when 
she Sends the message, it'll ends up in Unsent.  You need to alert the user to this condition (Unsent due to automatic-offline), else she might shut down the program expecting the message to have been sent.

A nice feature might be: a little slide-up window alert, like for notification, that displays *every* time something goes to Unsent, at least when that occurs due to being offline.  (That is, notification is unnecessary if user explicitly selects Send Later while online.)  Of course, such an alert isn't much use under Linux.

The Unsent on Online behavior is controlled by a pref.  If the user has selected Ask Me, they'll get prompted unless you add a check.  Maybe when user is notified of an Unsent message, and they have Ask Me or Don't Send selected,
they could get to override the existing pref for the next online.

OTOH, I use Don't Send only because I'm constantly putting test messages into my Unsent folder that I don't want to go out.  Most people, I'd think, would want Always Send selected, so maybe an override is unnecessary.

Generally, offline is not a Basic User Feature, so you have to be sure you don't trip people up by going offline automatically.

What about when starting up while system is offline?  Is it worth notifying then?  People with modems might not need the information, but someone expecting the network is always available (and has passwords saved) might not realize on startup that there are no new messages because of the network.

Comment 5

[Magnus Melin [:mkmelin]]

I think I would be in favour if of following the send later pref, or at least do /something/ when we get online again. Especially if the user has selected to always send (without asking) as soon as we get online, I interpret that to mean he just want the mail sent asap.

The ask dialog may be annoying, but I'm not sure connections generally would go online and offline frequently enough to make it disturbing. One can always change the pref in such cases.

This will be a very nice feature btw:)

Comment 6

[Scott MacGregor]

Attachment: very functional work in progress

Work in progress. This patch changes the offline state based on the network connectivity. It currently does nothing when we go back online (we don't prompt to send unsent messages as suggested by mcow and magnus). 

It's also integrates with our offline startup mode for mail.

Issues:

* In order for the network link detection code to work you have to set the following pref to false: network.autodial-helper.enabled in about:config. I have not researched what this pref does yet.

* I need to thunderbird ifdef the offline-startup.js changes so we don't effect seamonkey. 

* If you have VMWare installed on your machine this code won't detect your network connectivity going away. I had VMWare network detectors installed on my OS that always had IP addresses and that's the test the networking link code uses. Disabling those network connectors fixed the problem.

Comment 7

[Scott MacGregor]

Here's a question. Consider this scenario.

1) The network connection goes down so we automatically move to offline mode. The user did not choose to go offline.
2) You are configured to remember the previous online state when starting up. 

What state do we start up in?

Comment 8

[David :Bienvenu]

Seems like you wouldn't/shouldn't use "remember last state" on startup if you're using auto detect. But I'd say offline, because that was the last state.

Comment 9

[Grey Nicholson (they/them)]

(In reply to comment #7 and comment #8)
The last state was "online-if-possible", so we should attempt to start up online, irrespective of what the network was doing last time we looked. Of course if the network's still dodgy, auto-offline should be triggered.

Alternatively, the last state was auto-offline so we should start up auto-offline. Then if the network has returned, we should go back online automatically.

You might consider the online state to have three possibilities:
Online - assume the network is there
Auto - use the network if it's available
Offline - ignore the network

With automatic online/offline management off, the user chooses between Online and Offline; with it on, they choose between Auto and Offline.

Whichever of these three states the user was in should be restored.

Comment 10

[Grey Nicholson (they/them)]

(In reply to comment #9)
> The last state was "online-if-possible", so we should attempt to start up
> online, irrespective of what the network was doing last time we looked. Of
> course if the network's still dodgy, auto-offline should be triggered.
> 
> Alternatively, the last state was auto-offline so we should start up
> auto-offline. Then if the network has returned, we should go back online
> automatically.

...and these two are equivalent in terms of the result.

Comment 11

[Juan Lang]

> * In order for the network link detection code to work you have to set the
> following pref to false: network.autodial-helper.enabled in about:config. I
> have not researched what this pref does yet.

The pref, when enabled, implies that failed network connections should be retried once, in case the Windows autodialer dialog came up in response to a failed connection attempt.  A second attempt may succeed if the autodialer made a connection.

Having autodial enabled also implies that lack of a network connection doesn't necessarily mean what you think it does - it may mean that a network connection isn't presently available, but that one may become available if you try to connect even without one.

The autodial pref is enabled by default, but the autodial code queries the system at initialization to find out whether it should do anything.  The right solution, IMO, is to allow nsRASAutodial::QueryAutodialBehavior to be publicly callable, and only disable autoonline if both the autodial pref and QueryAutodialBehavior say autodialing should take place.

Comment 12

[Scott MacGregor]

Attachment: updated patch

I added a pref, offline.autoDetect for enabling / disabling this feature. This allowed me to modify offline-startup.js without breaking seamonkey since autoDetect is disabled for seamonkey.

This patch keeps things simple. When automatically going back online, we don't send unsent messages. If you have remember last state and you automatically get taken offline before you exit, we'll start you up in offline again.

**I don't think this has to be the final behavior. In fact I'm starting to agree with mcow and magnus about prompting / automatically sending unsent messages when we go back online (based on the unsent pref of course).**

Modifying those behaviors later should be pretty easy and I'd like to get feedback from folks by letting them try it out.

Of course to try this out after it lands you'll need to disable: network.autodial-helper.enabled
and make sure you don't have any connections that have IP addresses associated with them even when you lose your network connection (like my VMware connections).

Comment 13

[David :Bienvenu]

Comment on attachment 245029 [details] [diff] [review]
updated patch

looks good - but what about the mac, where auto-detect isn't implemented, as far as I know...

Comment 14

[Scott MacGregor]

(In reply to comment #13)
> (From update of attachment 245029 [details] [diff] [review] [edit])
> looks good - but what about the mac, where auto-detect isn't implemented, as
> far as I know...
> 

We don't have to do anything for the mac. Since the back end service isn't implemented, the client never gets moved offline in response to the network going down. If the service were to magically get implemented, things would just work. 

Comment 15

[Scott MacGregor]

This is now in the branch and the trunk so we can start collecting feedback on the desired behavior. I'll leave this bug open until we decide if we are going to prompt to resend messages when we go back online. 

Comment 16

[Scott MacGregor]

Interesting, apparently the networking call to manageOffline status is throwing an error on Linux. The linux service we are using to determine if the link connection is up is generating the error. cc'ing Mark who is seeing this.
 

Comment 17

[Scott MacGregor]

Oh, apparently the trunk version for the link update code for linux (Bug 312793) hasn't actually landed on the trunk yet. It's branch only and is still waiting for a trunk review.

Comment 18

[Phil Ringnalda (:philor)]

Even if it gets to working on Linux (which it doesn't for me, trunk *or* branch), you could improve the quality of bug reports from Mac users about totally unrelated things by putting a try{} catch{dump()} around the calls to nsIIOService2.manageOfflineStatus, so we don't report that totally expected (for us) NS_ERROR_FAILURE just because it's what's there in our error console.

Comment 19

[Magnus Melin [:mkmelin]]

I guess the exception would be bug 361702.

Comment 20

[Scott MacGregor]

The JS exception has been fixed and we've added a note in the release notes for window users to turn off the dial up pref to use this feature. There's nothing left in this bug for us to tackle.

Comment 21

[Mike Cowperthwaite]

What exactly should I be seeing here?  I unplugged my network cable, Windows 2000 put up a little indicator and said the network cable had been unplugged, but TB's indicator keeps showing Online (2b2-0207).

Then I clicked Get New Messages, and it tried to get mail, and the throbber sat there spinning and spinning.

When I unplugged, my little weather-widget from Yahoo updated shortly thereafter to "no connection"; and then as soon as I plugged back in, it re-fetched the current data and updated its display.

Meanwhile, TB kept spinning.  Clicking the worthless Stop button did nothing.  Clicking Get New Mail again gave me an error, "Folder is being processed."
Had to restart to reclaim my inbox.