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.

mass move, v2. qa to me.

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.

This should be Offline enhancement.

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.

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.

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?)

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).

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.

Comment on attachment 121163 [details] [diff] [review] Changes nsIOService to use automatic online/offline detection It takes two..

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.

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.

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 :)

darin, thx, look forward to the review. (Reminder, I'll be out of touch starting May 8.)

Darnit, style badness. Sorry for the spam.

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.

Darin, will you have a chance to look at this patch soon?

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.

bug 279160 implements this for linux using libnm

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.

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

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

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.

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 :-)

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.

This is updated to the interface in bug 312793. The automatic detection is confined to Win2K/XP.

(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.

OK, here's a revised version. I'd like bsmedberg to take a look at this before I commit it.

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.

(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.

Comment on attachment 219263 [details] [diff] [review] v1.1 patch Let's get this onto the 1.8 branch.

Comment on attachment 219263 [details] [diff] [review] v1.1 patch branch-approved.

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.

Comment on attachment 221102 [details] [diff] [review] Ts regression fix [fixed-on-trunk, fixed1.8.1] Looks good.

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.