So, I had no idea that we have a preference for this, but we do. Right now, Firefox tries to guess whether you are offline, and frequently gets it wrong. I posit that the only people that really want/need the offline mode are fine with triggering it manually. To do this, we should flip network.manage-offline-status to "False", so Firefox doesn't do this for you without you asking for it. I'm fine with shipping with Work Offline available in a menu (for now), but I don't think we should do it for you automatically. That's what I'm trying to fix with this bug. :)

Explicitly sets the pref to false.

Offline support isn't just a convenience thing, there are web-exposed APIs that make use of that state. I think it's a bit premature to give up on the idea of autodetection because it sometimes causes issues - ideally we should try to figure out what those issues are...

(In reply to comment #2) Oh true. I forgot about this: https://developer.mozilla.org/en/online_and_offline_events It looks like there's code out there that uses these. :\

Unassigning self until API implications are resolved.

The navigator.onLine property seems to be highly unreliable already, and I couldn't find any case where it breaks due to navigator.onLine over-reporting itself as true. By fixing this bug, we still conform to the HTML5 spec described here: http://www.whatwg.org/specs/web-apps/current-work/#browser-state

(In reply to comment #2) > Offline support isn't just a convenience thing, there are web-exposed APIs that > make use of that state. I think it's a bit premature to give up on the idea of > autodetection because it sometimes causes issues - ideally we should try to > figure out what those issues are... We aren't giving up the idea. We're just disabling autodetection until we can make it reliable, which is an adjective we could not truthfully use to describe it now.

To summarize: * We shouldn't let our broken detection of online/offline potentially get our entire user base inconvenienced to support a few web apps out there that make use of this * No other browser is supporting autodetection of this at the moment * We aren't removing Work Offline, you can still trigger it if you have use for it * The offline spec doesn't require any autodetection I'm going to request blocking for this because: * This is one of the top ten papercut issues identified frior to Firefox 4 * It has a patch that just changes one of our default settings * We shouldn't let the edge case of detecting offline and magically setting the user as offline when our code to do this is known to be deficient. We can reconsider enabling the autodetection when we are confident that it actually works.

This is a long-standing papercut that we've shipped with before. We should not hold back Firefox 4 on fixing it now. Blocking-. If the patch gets completed and reviewed and tryserver'd, then maybe ask for approval on it?

(In reply to comment #8) Patch completed and passed all non-random-orange tests on tryserver!

Comment on attachment 498800 [details] [diff] [review] patch I would like to know what the issues with autodetection are. AFAIK it defaults to "online" in the cases where it's uncertain/wrong ... erroneously reporting "offline" should be rare.

I just started up Minefield and found this. I was connected to wifi, with two other browsers (Firefox 4 beta 8 and Chrome) loading pages from the network normally.

Recently, we had a bug that we started as offline when the network manager is not available, fixed in bug 616520 and bug 617389.

(In reply to comment #12) > Recently, we had a bug that we started as offline when the network manager is > not available, fixed in bug 616520 and bug 617389. This seems to be neither of those bugs, as I'm building a tip-of-tree (as of yesterday) Minefield without any special compile-time flags.

Comment on attachment 498800 [details] [diff] [review] patch Actually I changed my mind here. If autodetection is unreliable, the correct solution is to fix it or disable it on the platform(s) where it's unreliable. Frank says it's unreliable on Mac, so we should disable it there and file a new bug to make it reliable and reenable it. That's what we did for NetworkManager on Linux. Do we have reports of it being unreliable on Windows? Note that the autodetection code is allowed to report "unknown" anytime it wants: http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsINetworkLinkService.idl so "reliable" just means "don't report 'online' or 'offline' unless you're really sure".

I see it being unreliable on Windows setups at home all the time. Some of the Dell laptops there have somewhat flaky wifi cards, and every once in a while FF drops into offline mode, and doesn't come back out. Not sure what else I can do to convince you here, I still think this hurts a lot of users for very marginal side benefits (especially since we're keeping Work Offline, just disabling the autodetect).

See Input, for example: https://input.mozilla.com/en-US/search/?product=firefox&q=offline Net usually disconnects while browsing. firefox goes in offline mode. When refresh page, remains offline . I have to restart to connect. (13 hours ago, Windows XP English (US))

To cover the variants, sorry for not including them in the previous comment: "Firefox is in "offline" mode and I can't continue surfing the web :(" (1 day ago, Windows 7, English (US)) "I put my computer to sleep last night. I woke it up this morning. Firefox was in offline mode. I never put it offline mode." (3 days ago, Windows 7, English (US)) "every other time i open it, it say try again, working offline. not cool! i need to work... and i have wi-fi !" (5 days ago, Windows XP, English (US))

Do we have any indication that flipping this pref solves the problems?

(In reply to comment #18) > Do we have any indication that flipping this pref solves the problems? Yes; flipping the pref prevents Firefox from automatically putting itself in Work Offline mode without the user explicitly doing so, e.g. from the File menu.

(In reply to comment #19) > Yes; flipping the pref prevents Firefox from automatically putting itself in > Work Offline mode without the user explicitly doing so, e.g. from the File > menu. I know that it does that theoretically, but what if there are other bugs that cause these symptoms to occur, that aren't related to link autodetection? Has someone who regularly sees this problem confirmed that things improved with the pref flipped?

(In reply to comment #20) According to the comments for the following add-on that simply exposes this hidden pref, yes. https://addons.mozilla.org/addon/13152/

>I see it being unreliable on Windows setups at home all the time. Some of the >Dell laptops there have somewhat flaky wifi cards, and every once in a while FF >drops into offline mode, and doesn't come back out. This is the same as my experience, it reliably goes into offline mode (the connection has in fact dropped), but it doesn't bring itself back out of it when the connection is back, it just provides the user with information about how they can go to a menu and try to manually re-enable it.

Why don't we just disable all the auto-detection code if all the platform interfaces are unreliable?

I mean, there's no point in even building the implementations of nsINetworkLinkService in netwerk/system if they're all too unreliable to use.

Fair enough, I don't know what the best / least risky option is. Happy with any of the approaches if the end result is the same, and it lands. :)

(and whether any other code uses nsINetworkLinkService and would break)

If any other code uses nsINetworkLinkService, presumably it gets horked too when the service produces incorrect results. But I think for now we should just use the pref. That way people can turn it back on again if they actually need this feature. And we can turn it on for testing if/when we want to fix the bugs in the link detection.

(In reply to comment #27) > But I think for now we should just use the pref. That way people can turn it > back on again if they actually need this feature. And we can turn it on for > testing if/when we want to fix the bugs in the link detection. …aka. review+? ;)

Comment on attachment 498800 [details] [diff] [review] patch Asking for approval to land this now that beta9 is tagged.

Comment on attachment 498800 [details] [diff] [review] patch a=beltzner

Pushed http://hg.mozilla.org/mozilla-central/rev/c0547fd3a3cc

The network detection works as expected on Linux/3.6.x. It's enabled by default in Fedora and we don't have reported any issues. But the nsNetworkManagerListener component is broken in beta9, nsNetworkManagerListener is not registered so: mNetworkLinkService = do_GetService(NS_NETWORK_LINK_SERVICE_CONTRACTID); always return NULL.

Could that be the reason of bug 627332?

(In reply to comment #34) > Could that be the reason of bug 627332? I don't think so. When mNetworkLinkService is NULL, firefox does not manage online/offline status and starts online by default, see: http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsIOService.cpp#271

(In reply to comment #33) > The network detection works as expected on Linux/3.6.x. It's enabled by default > in Fedora and we don't have reported any issues. Automatically putting you offline has other issues, like taking localhost offline too — this change just disables the autodetection until we have figured out the edge cases that we're currently not handling, since the bad behavior is confusing and affecting people right now. It's also notoriously unreliable on both OS X and Windows in my personal experience, Linux might be better here. > But the nsNetworkManagerListener component is broken in beta9, > nsNetworkManagerListener is not registered so: > > mNetworkLinkService = do_GetService(NS_NETWORK_LINK_SERVICE_CONTRACTID); > > always return NULL. Interesting. Can you file a separate bug for that?

(In reply to comment #36) > Automatically putting you offline has other issues, like taking localhost > offline too [...] Yup, the issue that's been annoying me for a while until I've found this issue. Trying to develop applications in a local web server and every now and then noticing things break just because I temporarily fully disconnected from the network (no ethernet cable nor wireless, during a network environment changeover - like home to company or the way around) feels just broken, although I could thing of good reasons for this to happen for the average user. Even when the issues are reduced, adding a user preference to allow disabling the automatic toggle would be nice (if it doesn't exist already).

(In reply to comment #37) > Even when the issues are reduced, adding a user preference to allow disabling > the automatic toggle would be nice (if it doesn't exist already). That's what we did. There's a toggle for making Firefox automatically manage it for you, and we turned that off by default — so you can turn it on if you want it. :)

The nsNetworkManagerListener registration bug is filed as Bug 627672

I backed this out to address bug 627332 for beta 10.

I see auto online/offline fail in Firefox fail for me often in Windows 7 on my Laptop. I setup PABX's through their web interfaces with my laptop I drag around site to site. Lots of PABX's have various issues with different browsers forcing you to remember what current browser works for what settings page. Anyways: 1)take laptop to some random network and connect to LAN 2)static assign or DHCP get an IP/gateway 3)due to local security measures on network the laptop is unable to connect to the internet. Could be any number or random security measures local IT has put in place. Network icon in Windows systray shows with yellow exclamation mark noting the issue with accessing the WAN. 4)navigate to local PABX address in browser eg 10.10.10.2 5)Windows requests for dialup to my default dialup account previously set 6)ignore dialup window, moving simply out of view and configuration of PABX on 10.10.10.2 works fine OR 6)close/cancel or click "work offline" for dialup request, all putting the machine into "offline" mode. Config on 10.10.10.2 is impossible with any browser until taken out of offline mode. I think this issue stems from some Windows bug as the same thing affects IE8 exactly the same. This annoys me at least several times a month.

Pushed again. https://hg.mozilla.org/mozilla-central/rev/81d830ef76fd

This property has been switched to false, waiting for the online/offline detection to be fixed. I'm wondering if we should reopen bug 426932 then: "navigator.onLine doesn't correctly update when network connectivity changes".

See https://bugzilla.mozilla.org/show_bug.cgi?id=654579#c9

See also https://bugzilla.mozilla.org/show_bug.cgi?id=756364