I noticed initially that Thunderbird's automatic offline/online detection wasn't working on nightly builds. I've since done some more testing and found Firefox doesn't work either. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090118 Shiretoko/3.1b3pre Ubiquity/0.1.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Lightning/1.0pre Shredder/3.0b2pre What I did to double check: 1) Enter the following line into the error console with networking available and select evaluate: Components.classes["@mozilla.org/network/network-link-service;1"].getService(Components.interfaces.nsINetworkLinkService).isLinkUp => Returns: true. 2) Go offline on your mac interfaces (disable, select offline mode etc), and evaluate the line again => Returns: true (expected: false) If I replace isLinkUp with linkStatusKnown and try again, this always returns true. I've not had anyone confirm these steps yet, but David said in bug 473483 comment 7 that he was having problems. However, if someone could confirm this bug I think it would be useful. I'm not sure how this regressed (if at all) - it was working at one stage, and there's been no apparent changes to the code as far as I can tell (http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/system/mac/nsNetworkLinkService.mm)

Just tried with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090117 Minefield/3.2a1pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Lightning/1.0pre Shredder/3.0b2pre and I can reproduce no problems, it just keeps telling me true, no matter what I do to make myself offilne.

gozer: Step 2 in comment 1 says that false is expected, which suggests to me that the behavior you're seeing is in fact a confirmation of this bug. Am I misinterpreting?

I guess I should have said 'and I can reproduce it no problems' So, yes, you are correct, I am confirming that this bug exists and I've reproduced it on my own Mac. I guess that makes it NEW

I can reproduce it too. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081201 Thunderbird/3.0b1

This feels like a blocker to me; nominating.

I can't repro, nor can dcamp. I can repro the thunderbird offline status failure, but the STRs in comment #0 about the network link service seems to work as they should for me.

For the people that can reproduce (specifically using nsINetworkLinkService.isLinkUp, not just whether "Work Offline" is properly ticked): * What sort of network interfaces do you have configured? * How are you taking them offline? * Just to make sure, it can take a few seconds from disabling all the interfaces before the service is notified.

So far, my investigation seems to indicate that the network link service has the right state when asked, but that the NS_IOSERVICE_OFFLINE_STATUS_TOPIC notifications don't happen (in my case, don't happen until shutdown, which is odd and useless =).

Never mind. I did the test wrong earlier. Now that I'm doing it correctly, I can't reproduce Mark's test case. The times when I had the problem I was using the airport interface and went offline by closing the lid of the macbook which put it to sleep. So far I've tried to reproduce the problem a couple of ways. 1. Using ethernet interface (which i normally use) disable it in the network section of System Preferences. 2. Switch to the airport interface and use the Sleep item under the apple menu.

I looked a bit closer, and here: http://hg.mozilla.org/comm-central/file/f387942413e2/mail/app/profile/all-thunderbird.js#l268 the code looks like: #ifdef XP_UNIX pref("offline.autoDetect", false); #else // Windows and Mac can automatically move the user offline or online based on // the network connection. pref("offline.autoDetect", true); #endif But XP_UNIX appears to be set on osx, so autodetection is turned off. If I manually set offline.autoDetect to true and restart, the status is updated as I go on and offline (though it doesn't appear to be set correctly at startup, but that's presumably a different problem).

thanks for the analysis dcamp! patch attached, using idiom from firefox.js

It looks like this is probably fixed, but so I can verify/review, can someone help me with the following issue? I can't seem to get the error console to work with the steps given to reproduce this bug: I punch in Components.classes["@mozilla.org/network/network-link-service;1"].getService(Components.interfaces.nsINetworkLinkService).isLinkUp (all as one line) in the error console, hit eval, and get Error: Components.classes['@mozilla.org/network/network-link-service;1'] is undefined Is there something I need to do to get the network-link-service to load? thanks.

Note: the patch we've got so far is just for Thunderbird--looks like we need similar for Firefox, no?

re: comment #12: are you testing this with nightly builds of Shredder? re: comment #13: no, this pref doesn't exist for Firefox. I don't know the Seamonkey status.

(In reply to comment #7) > * What sort of network interfaces do you have configured? I have several interfaces on the mac book: Ethernet, AirPort, Bluetooth, Firewire with 2 configurations that I'm testing with "Automatic" (Ethernet & Airport will enable if they can), "Offline" (all devices inactive). > * How are you taking them offline? - I'm in the Automatic configuration and I turn Airport off. - or I select the offline configuration. > * Just to make sure, it can take a few seconds from disabling all the > interfaces before the service is notified. I've been waiting whilst writing this and its still reporting true. If I go into Safari and try and visit a page it tells me that I'm not connected to the internet, and all the network devices have failed. I'm on 10.5.4 btw. Oh and the offline.autoDetect pref is obviously wrong, but I've overridden it to try in my preferences (before reporting this bug).

Comment on attachment 358301 [details] [diff] [review] [checked in] pref patch Regardless of my issues, the pref definitely needs fixing so r=me. I've checked this in as well: http://hg.mozilla.org/comm-central/rev/050c5dde44b0

I can't seem to reproduce the behavior in this bug. I've tried the exact same build as the 1st reporter (except I'm not using Ubiquity): Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090118 Shiretoko/3.1b3pre. I've also tried yesterday's Shredder nightly build (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shredder/3.0b2pre). In both cases I get "true" when my Airport is on, and "false" when it's not, over repeated iterations. I've got cycles to work on this bug, but it's going to be hard to make any progress without being able to duplicate the error. Ideas?

I just tried reproducing this, and I just noticed something that might have been overlooked. It takes > 5 seconds on my laptop to detect the network cable has been unplugged, so the first 2-3 times I run the code, I still get true, but if I give it time, it eventually detects the link as down and returns false, as it should.

I've done some additional work and debugging on this. My MacBook still won't give the correct notifications to Thunderbird (or Firefox) to get it to go offline or change the isLinkUp attribute to false. What I have discovered, is when I turn Airport off, or disconnect an ethernet cable (at different times depending on the initial network state), is that nsNetworkLinkService::UpdateReachability does get called a few seconds later. However the if (!::SCNetworkReachabilityGetFlags(mReachability, &flags) || flags == 0) comes into action and so the network status is set as unknown. Safari tells me that sites are unreachable, though that could be a combination of detecting the unknown status and not actually being able to reach the site. My configuration is that I always have FireWire and Bluetooth inactive, and Ethernet and AirPort can be active at different times. I couldn't find anything else that was active that could be causing it to go unknown rather than offline. My suspicion is that my network options may be corrupt in some manner - I had to reinstall a while ago and they've not behaved quite right since then. I'm going to be attempting a complete reinstall this weekend (assuming the drive I need to use for backup arrives), so I think I'll have to see if that fixes it. Any ideas on debugging what my mac is doing it would be useful.

on the assumption that it's not widely reproducible, removing blocking flag

(In reply to comment #20) > on the assumption that it's not widely reproducible, removing blocking flag I see this too, but I'm suspecting whether it's local to me or not. STR: - Close the lid of your laptop with WiFi on and Shredder in online mode. - Laptop should standby. - After waiting for a few minutes, open the lid, laptop should restore from standby, OS WiFi should reconnect and go online. - Shredder remains in offline mode as denoted by the "no bulb" icon in the bottom left, as well as when Get All Messages from All Accounts is pressed. This happens even though it was not manually set to go offline previously. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090128 Lightning/1.0pre Shredder/3.0b2pre I usually end up restarting Shredder to work around this issue, which has seemingly only surfaced since the start of this month. blocking-thunderbird3 should be re-nominated in the event that someone reproduces my STR.

Renom blocking -- This is affecting me so bad at school, where I constantly close my laptop lid to run about school, usually with Shredder running and online. When I reuse my laptop and open the lid, OS Wifi connectivity comes up and works online, but Shredder doesn't go online by itself. Mac Leopard. Possibly due to davida's pref patch?

(In reply to comment #22) > Renom blocking -- This is affecting me so bad at school, where I constantly > close my laptop lid to run about school, usually with Shredder running and > online. When I reuse my laptop and open the lid, OS Wifi connectivity comes up > and works online, but Shredder doesn't go online by itself. Mac Leopard. > > Possibly due to davida's pref patch? Spun off as bug 475922.

I've been having a lot of trouble getting the problem to recur again. Mostly I don't see the problem because I normally use the machine like a desktop with ethernet and an external monitor with the lid closed. However, last night and this morning I spent a bunch of time unwired and still couldn't get the problem to recur. Energy saver put the machine to sleep a few times and I put it to sleep a bunch by closing the lid. Each time it woke up the network re-connected quickly and by the time i was able to evaluate isLinkUp, it was always true. I received several new mails but I didn't send anything. When I was on vacation where I had the trouble with Thunderbird, I was connecting to an 802.11g network but here I have 802.11n so I thought maybe the slower network had a slower connection time which was causing a problem. However I finally ran into a problem plugging the machine back in. I disabled the airport and enabled ethernet. At that point I noticed that the candy cane busy icon at the bottom was going so I investigated further. linkStatusKnown and isLinkUp both evaluate to true but I am unable to send or receive mail. When I try to send, I get "Looking up <outgoing smtp host>". I tried turning the airport back on but thunderbird is still stuck. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081201 Thunderbird/3.0b1 Components.classes["@mozilla.org/network/network-link-service;1"].getService(Components.interfaces.nsINetworkLinkService).linkStatusKnown -> true Components.classes["@mozilla.org/network/network-link-service;1"].getService(Components.interfaces.nsINetworkLinkService).isLinkUp -> true

(In reply to comment #23) > (In reply to comment #22) > > Renom blocking -- This is affecting me so bad at school, where I constantly > > close my laptop lid to run about school, usually with Shredder running and > > online. When I reuse my laptop and open the lid, OS Wifi connectivity comes up > > and works online, but Shredder doesn't go online by itself. Mac Leopard. > > > > Possibly due to davida's pref patch? > > Spun off as bug 475922. That said, my issue may have been some other bug, removing nom request.

also, there's a chance that it was broken all along, but i didn't notice because I never tried to send mail. I seem to remember that while i was on vacation I only noticed the problem while sending mail.

I have seen this occasionally on my personal laptop when waking my machine from sleep. After I open the lid and try to check for updates, I get a message that FF is offline. The next time I check for updates it finds the update so it seems as if takes a small amount of time to actually detect the wireless connection. This happens with both 1.9.1 and trunk.

Next time someone finds themselves in a state where firefox/thunderbird's status doesn't match the status of the machine, running the following commands would be helpful to figure out where the problem is: Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService2).manageOfflineStatus; Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService2).offline; in addition to the previously-mentioned isLinkUp and linkStatusKnown. As mentioned in comment #18, it can take a few seconds for the system to let us know that the online/offline status has changed.

(In reply to comment #28) Actually I copied these steps over to bug 475922: I'd like this bug to stay focused on problems with nsINetworkLinkStatus (specifically, if isLinkUp and linkStatusKnown are returning incorrect values).

(In reply to comment #28) I hope that helps to track down the problem. Would be great to have it fixed soon because its really annoying. Here my results: > Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService2).manageOfflineStatus; true > Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService2).offline; false Components.classes["@mozilla.org/network/network-link-service;1"].getService(Components.interfaces.nsINetworkLinkService).linkStatusKnown true Components.classes["@mozilla.org/network/network-link-service;1"].getService(Components.interfaces.nsINetworkLinkService).isLinkUp true

Hi - I'm wondering if the patch introduced on 23rd could have broken something in behavior after fetching mail on OSX? I'm seeing a consistent, repeatable crash on OSX which happens after getting the last message in a (POP) mailbox. It happens on every build since 23rd and on all mailboxes (so I don't think its corruption). Going back to the nightly of 23rd and everything works fine. I'm looking for a patch - possibly an OSX specific patch - that is causing an exception: 10:50:02.671 thunderbird-bin[1508:10b] Mozilla has caught an Obj-C exception [NSInvalidArgumentException: Invalid parameter not satisfying 'uniqueId != nil && [uniqueId length] > 37'] Its reported as bug 475205, but I can't get any other OSX users interested enough to report if its happening for them as well.

(In reply to comment #31) > Hi - I'm wondering if the patch introduced on 23rd could have broken something > in behavior after fetching mail on OSX? Mitra, it will only be likely to have affected you if you are doing things like going online/offline or sleeping - we flipped a pref that has been flipped to the same state before I believe.

To avoid confusion, I've raised bug 480324 to cover the issues I have with offline detection not working in the *core* code. Therefore I'm going to close this bug as fixed as it did turn auto detect on - note however that bug 473483 has currently turned it off, and will hopefully turn it back on soon. I'm closing this bug so we haven't got multiple bugs covering the same issues.