Closed Bug 76111 Opened 19 years ago Closed 14 years ago

Auto detect online/offline status on Windows

Categories

(Core :: Networking, enhancement, P2)

All
Windows XP
enhancement

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: mozilla, Assigned: darin.moz)

References

(Depends on 1 open bug)

Details

(Keywords: fixed1.8.1)

Attachments

(4 files, 7 obsolete files)

Suggested enhancement: mozilla could detect automatically whether the
computer is offline/online rather than depending on the user to
click the icon.  (This should be optional behaviour selectable in
preferences, as it might not suit all users.)

In Windows 2000 it would be possible to have mozilla go offline
automatically when the user pulls the network cord out of their
laptop, for example.  I'm not sure whether ethernet connectivity
can be tested easily on other platforms.

[At present, I unplug my laptop at the office, hibernate it, and then get
pestered by the "Connection refused to server" messagebox while trying
to work on the train as mozilla tries to check my POP mailbox.]

I'd like to have a bash at implementing this if people agree it's
worthwhile.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
mass move, v2.
qa to me.
QA Contact: tever → benc
Max: Definitely worthwhile, dailup users will thank you!
This is pretty complicated to do in conception (especially physical
disconnection detection), so I'm marking this just for mail, and sending it to them.

Browser connect/disconnect features are implemented separately.
Assignee: mozilla → mscott
Status: ASSIGNED → NEW
Component: Networking → Networking - General
Product: Browser → MailNews
QA Contact: benc → huang
Summary: Automatic online/offline status → [RFE] Auto detect online/offline status
This should be Offline enhancement.
Component: Networking - General → Offline
QA Contact: huang → gchan
Attached file C source for test app
Attached file Makefile for above
Test app above detects whether we have any usable network interfaces available
at the moment.  Windows only (at present), should theoretically work on Windows
4.0 SP4 and newer OS's.  Can someone help make sure that it does work on all
these platforms; I've tested W2K only?  Not sure about 95.

(There is also "support" in the API for event notification of network interfaces
going up and down.  I couldn't make this work after a lot of trying, and I found
some other people who couldn't either.  However, a non-polled approach would
obviously be better if possible.)
hrm looks like you're checking for ipv4 addresses.  A machine could be running 
ipv6 only (and moz should be perfectly happy w/ that)...

there's also GetBestInterface which may be of some use to someone...
I got a message that this bug should have been removed:
"Reason: This bug has been moved to a different product"

Can someone explain why? Autodetect online/offline status should be very useful,
certainly in a windows 2000 environment using a notebook that is sometimes (at
work) connected and sometimes (at home) only rarely connected by using a dialup
network.

Blocks: 95142
Mail/news groups should detect offline state from browser and not try to get
mail from accounts, even if check for new mail on startup is checked, I'm not
sure if this is a seperate bug, but its got to be possible as a start for this
here.. 
actually that may be working in 095.. I cant find out right now if that is the
case as I dont have a pop email and webmail doesn't work within mozilla.
This feature is also important to users who (a) buy a new computer with Netscape
or Mozilla pre-installed or (b) install from the browser from CD.  In either
case, the users may start the browser before being connected.  The current
experience is to watch the logo animate for several minutes before giving
a server access error message.
You could use a methodology like "ping DNS server" or "ping default router"...

I don't know if there is a single, good Xplat way of doing this...
*** Bug 120951 has been marked as a duplicate of this bug. ***
Should this bug be marked future?  MScott, maybe you're the wrong owner?
*** Bug 144847 has been marked as a duplicate of this bug. ***
*** Bug 165763 has been marked as a duplicate of this bug. ***
Relies on a couple added files, to be uploaded separately.
Attached file Online/offline implementation (obsolete) —
Only functional on Windows (but shouldn't break other platforms).  I could
implement polling for IPv4 interfaces in a reasonably-xp way, but I don't want
to break IPv6 support.	Suggestions for IPv6 welcome.

Tested on Win2k inserting/removing my PCCard NIC.  Should at least run on all
flavors of Windows, though automatic detection won't work on Win95.
cc me
darin, could you take a look at this patch?  (And maybe suggest ways to use NSPR
to make this work XP?)
Attached file Online/offline implementation (obsolete) —
Last version could've gotten confused on Win98 by extraneous card
insertion/removal events, like plugging in cameras and mice and whatnot.

Test cases:
- start Mozilla with a network interface with link and an IP address.  Should
come up in online mode.
- w/Mozilla running (and with a link and valid IP address), toggle
online/offline mode.  Should change mode according to your selection.
- start Mozilla w/no link or no network interface.  Should come up in offline
mode.
- w/Mozilla running, unplug network cable or card.  Should go into offline
mode.
- Plug cable/card back in w/Mozilla in offline mode.  Should go back into
online mode.
- w/Mozilla in online mode, select offline mode.  Unplug cable/card and plug it
back in.  Should stay in offline mode (I don't override a user-chosen mode).
- w/cable/card unplugged, try to switch to online mode.  Shouldn't be able to
(until cable/card is plugged back in).
Attachment #121164 - Attachment is obsolete: true
Bad coder, I mentioned the test cases I've tried, but not the ones I haven't tried:
- does this work w/dialup connections?
- does this interfere with the autodial setting?

I don't have a dialup to test with, help welcome.
Attachment #121224 - Flags: review?(darin)
Comment on attachment 121163 [details] [diff] [review]
Changes nsIOService to use automatic online/offline detection

It takes two..
Attachment #121163 - Flags: review?(darin)
You might also want to give some consideration to PPPOE users, where the
ethernet might be on even if you aren't "dialed".

I'm sure you could fine some people w/ dialup to try the patch.
Ben:  yikes, I didn't think of PPPoE.  I wonder how that'll work..  anyway, this
should have a pref to enable/disable, like the original poster says.  Can
disable where it doesn't work.

bzbarsky:  with a pref to disable, I'll take a whack at a UNIX version that'll
support IPv4 initially.  It'll have to poll, unfortunately.

This patch does tromp on autodial.  I'll work on that, and add a pref, and
repost.  Anyone else find it ironic that for autodial to work I have to enable
it through IE?
i won't be reviewing this until maybe next week at the earliest.
Attached patch Improved patch (obsolete) — Splinter Review
The "autoonline" feature is now enabled with the pref
network.autoonline.enabled (it's disabled by default).

This doesn't interfere with the autodial feature:  if autodial is enabled (by
default it is), and if the system settings say autodial, then autoonline won't
do anything.
Attachment #121163 - Attachment is obsolete: true
Attached file Online/offline implementation (obsolete) —
Works around bugs and missing features in different versions of the IP helper
API.  Still Windows-only.

Could use wider testing.  Still, it works pretty well for me :)
Attachment #121224 - Attachment is obsolete: true
Attachment #121163 - Flags: review?(darin)
Attachment #121224 - Flags: review?(darin)
Attachment #121548 - Flags: review?(darin)
Attachment #121558 - Flags: review?(darin)
darin, thx, look forward to the review.  (Reminder, I'll be out of touch
starting May 8.)
Attached file Online/offline implementation (obsolete) —
Darnit, style badness.	Sorry for the spam.
Attachment #121558 - Attachment is obsolete: true
Attachment #121558 - Flags: review?(darin)
Attachment #121571 - Flags: review?(darin)
As a notebook user who is sometimes-on-dialup and sometimes-on-broadband and
sometimes-on-a-lan-with-no-internet-access, I would prefer an alternate
solution: I would like to see Mozilla able to be told via script when to go
online and offline. It would be fairly trivial for me to configure my system to
issue a 'mozilla -remote' command upon connection to a network that I know has
internet access, if such functionality were available in Mozilla.

Also, this would give me more control over what outgoing traffic mozilla issues.
I would be very wary of any program's methods of auto-sensing connectivity when
such functionality is not yet universally defined on an operating-system level.
Seems from my lay-person's perspective like this feature could be more simply
implemented and therefore released sooner than auto-sensing, as well.

Many humble apologies if I have misdirected this feature request.
Re: comment #34. Michael, what you are requesting is known as bug 139141. Both
features are IMO a good idea, but these are pretty separate issues.
Assignee: mscott → bienvenu
Depends on: 88194
Darin, will you have a chance to look at this patch soon?
Summary: [RFE] Auto detect online/offline status → Auto detect online/offline status
Yes, I plan to review and help land this for Mozilla 1.8 ... sorry, I just
haven't had the cycles for the 1.7 milestone.
Product: Browser → Seamonkey
bug 279160 implements this for linux using libnm
Depends on: 279160
Cool.  Any chance of a review of this one?
The current patch is all in necko, so I'm going to move this bug over to Core:
Networking with the aim of actually getting some of these changes incorporated
into Gecko 1.8.
Assignee: bienvenu → darin
Component: MailNews: Offline → Networking
Product: Mozilla Application Suite → Core
QA Contact: grylchan → benc
Target Milestone: --- → mozilla1.8beta2
Depends on: 282442
Status: NEW → ASSIGNED
Priority: -- → P2
I'm curious about the nsINetInterfaceDetector interface's use.  What exactly is
a "network-interface-*appeared" event?  Is it a DOM event or some other type of
event?  Also, what would a use case of this interface look like?

Is this how it's meant to be used:

// in my window onload handler
var dector =
Components.classes["@mozilla.org/network/net-interface-detector;1"].getService();
dector.init();

// when i need to check for network presense
if( dector.haveNetworkInterface() ){
  // do something with a network connection
}
else{
  // no network do something else
}

// in my window onunload handler
dector.init();

Finally, what's the status of this bug and does it still look like it'll land in
time for 1.5.
I did a little checking for what it would take to get something like this
working on the mac... I found this site which has a very simple solution:
http://www.cocoadev.com/index.pl?CheckingOnlineStatus
Target Milestone: mozilla1.8beta2 → mozilla1.9alpha
It's really too bad this isn't going to make it into 1.8 for xulrunner.  This
would really improve the story for thin client application developers to have a
well defined method for determining online/offline status
Blocks: 308047
Long ago I promised a UNIX version and never delivered.  Still hoping for a review.. I can't think of a non-polling way to do a UNIX interface, but one could poll using ioctl(SIOCGIFCONF).  If no non-loopback address is detected, the machine is offline.
Bug 312793 has a patch proposing a very similar interface and an implementation for Linux based on NetworkManager, check it out.
Blocks: 216490
The new API introduced by the patch for bug 312793 has landed.  It should be fairly straightforward to migrate the patch in this bug to that interface.  I hope to work on this soon, but if someone else is interested in working on it, please let me know :-)
Attachment #121548 - Flags: review?(darin)
Attachment #121571 - Flags: review?(darin)
This patch detects when a network card is inserted or removed easily enough, but doesn't handle link sensing at all.  If I use NotifyAddrChange in Windows 2000/XP, it tells me about link changes too, but it's not available in Win9x.

Does anyone have any bright ideas about how to write this for Win9x?  If not, I'll just do this the simpler way.

Either way, I'm migrating it to the new API, and I hope to have a patch ready next week sometime.
IMO, it matters most that we have something that works well in Win2k and later.  If Win9x behavior is not so great, that's okay.
Attached patch Updated to new interface (obsolete) — Splinter Review
This is updated to the interface in bug 312793.  The automatic detection is confined to Win2K/XP.
Attachment #121548 - Attachment is obsolete: true
Attachment #121571 - Attachment is obsolete: true
Attachment #218934 - Flags: review?
Attachment #218934 - Flags: review? → review?(darin)
(In reply to comment #47)
> Created an attachment (id=218934) [edit]
> Updated to new interface
> 
> This is updated to the interface in bug 312793.  The automatic detection is
> confined to Win2K/XP.
> 

Does, this mean all we need is a little testing and a Mac Version?
Well, a review would be nice too, and bug 312793 needs to be sorted out (single combat?) but basically, yeah.
Juan: I just had to make one tweak to your patch to get it to work.  I also had to disable the autodial pref.  But, it works great!  Thanks!!  I have a few more tweaks that I want to make, and I'll post a revised patch shortly.
(In reply to comment #50)
> I also had to disable the autodial pref.

Awesome, thanks for the review.  I have some questions about how this should work with autodial:
1. The autodial pref defaults to on, which makes sense currently because it has no effect on systems that will not dial.  With this patch, you have to turn it off to get this behavior.  Does it make sense to expose a "autodial is on, and will actually do something" check?

2. Alternatively to 1., this could observe pref changes, and start/stop the NotifyAddrChange thread depending on the value of the autodial pref.  Should it?

3. On systems where the NotifyAddrChange thread isn't running, the isLinkUp property is only initialized at app startup.  Should it instead check whenever it's called?
(In reply to comment #51)
> Does it make sense to expose a "autodial is on, and
> will actually do something" check?

Yup, this is what I was thinking we should add.  It might be something that we do as a separate patch, however.


> 2. Alternatively to 1., this could observe pref changes, and start/stop the
> NotifyAddrChange thread depending on the value of the autodial pref.  Should
> it?

I prefer being able to poll the autodial system.


> 3. On systems where the NotifyAddrChange thread isn't running, the isLinkUp
> property is only initialized at app startup.  Should it instead check whenever
> it's called?

Maybe.  That might help.  I'm going to post a revised version of your patch sometime today hopefully.
Attached patch v1.1 patchSplinter Review
OK, here's a revised version.  I'd like bsmedberg to take a look at this before I commit it.
Attachment #218934 - Attachment is obsolete: true
Attachment #218934 - Flags: review?(darin)
Attachment #219263 - Flags: superreview?(benjamin)
Attachment #219263 - Flags: review+
Comment on attachment 219263 [details] [diff] [review]
v1.1 patch

r=me for build-config changes, do you need me to do a code review as well? I'm not sure I know the networking APIs to do that easily.
Comment on attachment 219263 [details] [diff] [review]
v1.1 patch

IMO we should stop adding CIDs to nsNetCID.h - people shouldn't use the contract IDs. can we put this in a private file instead?
Comment on attachment 219263 [details] [diff] [review]
v1.1 patch

Please re-request sr if you need me to do a detailed code review.
Attachment #219263 - Flags: superreview?(benjamin)
(In reply to comment #55)
> (From update of attachment 219263 [details] [diff] [review] [edit])
> IMO we should stop adding CIDs to nsNetCID.h - people shouldn't use the
> contract IDs. can we put this in a private file instead?

Yeah, that's a good idea.  Maybe nsNetCIDInternal.h or something like that.
> Yeah, that's a good idea.  Maybe nsNetCIDInternal.h or something like that.

Actually, I think that should happen as a separate bug.  There are many CIDs listed in that header file.
This bug is now fixed.  Morphing this bug to be Windows-specific since Linux support was done in a separate bug.  I'll file a new bug about implementing nsINetworkLinkService on OSX.

Also, I filed bug 336277 on factoring nsNetCID.h into private and public parts.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
OS: All → Windows XP
Resolution: --- → FIXED
Summary: Auto detect online/offline status → Auto detect online/offline status on Windows
Blocks: 336284
Blocks: 336333
Comment on attachment 219263 [details] [diff] [review]
v1.1 patch

Let's get this onto the 1.8 branch.
Attachment #219263 - Flags: approval-branch-1.8.1?(shaver)
Comment on attachment 219263 [details] [diff] [review]
v1.1 patch

branch-approved.
Attachment #219263 - Flags: approval-branch-1.8.1?(shaver) → approval-branch-1.8.1+
fixed1.8.1
Keywords: fixed1.8.1
It looks like this is responsible for a 25-27% startup performance regression :(

More investigation needed...
It looks like the culprit is the instantiation of this implementation of nsINetworkLinkService.  On my machine, it takes about 655 milliseconds.  I blame the call to CheckLinkStatus in nsNotifyAddrListener::Init.  Yup, removing that one line results in Init taking only 1 millisecond.  OK, patch coming up.
Attachment #221102 - Flags: review?(benjamin)
Attachment #221102 - Flags: approval-branch-1.8.1?(shaver)
Comment on attachment 221102 [details] [diff] [review]
Ts regression fix [fixed-on-trunk, fixed1.8.1]

Looks good.
Attachment #221102 - Flags: review?(benjamin)
Attachment #221102 - Flags: review+
Attachment #221102 - Flags: approval-branch-1.8.1?(shaver)
Attachment #221102 - Flags: approval-branch-1.8.1+
Attachment #221102 - Attachment description: Ts regression fix → Ts regression fix [fixed-on-trunk, fixed1.8.1]
For folks who have been waiting to see this behavior get reflected in Thunderbird, I'm tracking that work in Bug 359134.
This works on both Firefox and Thunderbird trunk (3.x-pre versions), but neither Firefox nor Thunderbird 1.8-branch nightlies (2.x versions), running Windows XP.
On the trunk, both apps switch to offline mode a couple of seconds after I press the button do disable the WLAN adapter of my notebook, as expected.
But on the branch, they stay online.
May I kindly ask what would be the proper way to turn this off? I think some users could be interested in some kind of offical & working how-to. Much obliged.
My question specifically referred to FF3. I asked here because this entry was referenced in bug 436815.
You need to log in before you can comment on or make changes to this bug.