Last Comment Bug 654579 - navigator.onLine status for Offline Applications (navigator.onLine always returns true for desktop Firefox unless "work offline" is manually selected)
: navigator.onLine status for Offline Applications (navigator.onLine always ret...
Status: RESOLVED FIXED
: dev-doc-complete, relnote
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: unspecified
: x86 Windows 7
: -- normal with 6 votes (vote)
: mozilla41
Assigned To: Valentin Gosu [:valentin]
:
Mentors:
: 783516 796978 827322 1058950 1157943 (view as bug list)
Depends on: 1182025 1134596 1139453
Blocks: 886487 ServiceWorkers-v1 1157943
  Show dependency treegraph
 
Reported: 2011-05-03 15:15 PDT by Schalk Neethling
Modified: 2016-05-10 14:02 PDT (History)
38 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
41+


Attachments
imported patch _enable_network_detection.patch (1.26 KB, patch)
2015-06-10 15:03 PDT, Valentin Gosu [:valentin]
daniel: review+
Details | Diff | Review
Set the network.manage-offline-status to true for desktop (1.29 KB, patch)
2015-06-19 11:05 PDT, Valentin Gosu [:valentin]
no flags Details | Diff | Review

Description Schalk Neethling 2011-05-03 15:15:42 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.60 Safari/534.24
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0

As part of the Offline Web Applications specification (http://www.w3.org/TR/offline-webapps/) there is a property set on the navigator object that will return whether a user is online or offline e.x.

navigator.onLine;

Currently Firefox 4 always returns true for the above check even when disconnected from the internet. There are also two events of the window Object that fires when a user connects or disconnects, these events are not being fired either.

The non firing events will not be such a concern if Firefox returned undefined for the navigator.onLine call instead of the current false, positive. 

Reproducible: Always

Steps to Reproduce:
1. Add the following code to a HTML page:
if(navigator.onLine) {
    console.log("online");
} else {
    console.log("offline");
}
2. Open the webpage while connected to the internet. You will find that the online is logged to the console.
3. Now disconnect from the internet and refresh the page. The above will still report that you are connected i.e. online

Actual Results:  
Whether connected or not navigator.onLine always returns true

Expected Results:  
The property should either be set to the correct states or return undefined if this part of the specification is not yet implemented to avoid false/positives.
Comment 1 Boris Zbarsky [:bz] 2011-05-03 21:32:42 PDT
The spec says at <http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#navigatoronline>:

  The navigator.onLine attribute must return false if the user agent will not
  contact the network when the user follows links or when a script requests a
  remote page (or knows that such an attempt would fail), and must return true
  otherwise.

We return false when we're in offline mode.  Firefox 4 only enters offline mode if the user explicitly requests so (it's an option in the file menu).  If we're not in offline mode, we will try to access the network if you try to "follow a link" or "request a remote page".  So per spec, we're returning true unless we're in offline mode.
Comment 2 Schalk Neethling 2011-05-04 02:23:23 PDT
Hey Boris,

Thank you for your reply. This implementation is different to the way that Google Chrome has implemented it. Chrome will return the 'correct' status on page load and also fires the online and offline events when a user connects or disconnects from the network without a page reload.

This is one of those situations where the spec is being interpreted differently by two different browser vendors and will cause confusion for developers that is surely not the intent of the W3C the WHAT-WG, nor Firefox. 

For an example of what I mean about Crome's implementation, please have a look at the following page:

http://thebrowsereview.com/demos/offline_webapps/

I believe that the implementation by the Chrome team is much more useful to a developer than the current implementation by Firefox, thoughts?

Kind Regards,
Schalk

(In reply to comment #1)
> The spec says at
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#navigatoronline>:
> 
>   The navigator.onLine attribute must return false if the user agent will not
>   contact the network when the user follows links or when a script requests a
>   remote page (or knows that such an attempt would fail), and must return true
>   otherwise.
> 
> We return false when we're in offline mode.  Firefox 4 only enters offline mode
> if the user explicitly requests so (it's an option in the file menu).  If we're
> not in offline mode, we will try to access the network if you try to "follow a
> link" or "request a remote page".  So per spec, we're returning true unless
> we're in offline mode.
Comment 3 Boris Zbarsky [:bz] 2011-05-04 05:51:21 PDT
> This implementation is different to the way that Google Chrome has implemented
> it

It's also different from Firefox 3.6, where we tried to "auto-detect" whether we have a network available.  The problem is that the auto-detection is wrong in some cases, and in particular that it sometimes decides there is no network when there could be one (e.g. auto-dial situations).  Note that returning false in that situation would be a spec violation; I don't know whether Chrome thus violates the spec.

I don't see how Chrome's implementation is more useful, by the way.  As the spec explicitly points out, just because there is a network link up doesn't mean there's internet connectivity.  So even if navigator.onLine is true you may still not be able to reach any particular site (or any site at all), and your code needs to deal with that.
Comment 4 Schalk Neethling 2011-05-04 12:47:06 PDT
Hey Boris,

Fair enough, I guess the point I am trying to make is that I did find the implementation of the same standards to be different between, in this case, Chrome and Firefox and, that I would hope that the browser vendors of, especially, the open browsers will communicate and ensure that their implementation of the standard matches.

I do agree that one should code defensively and, the fact that navigator.onLine returns true should not give you complete peace of mind. The bigger issue is,  as stated before, that the implementation should be similar to make using this simpler for developers i.e. we can expect the same behavior in different browsers.

Thanks for all of your feedback on this issue.

Schalk
Comment 5 Schalk Neethling 2011-05-04 13:00:14 PDT
Hey Boris,

Something I forgot about, why does Firefox 4 tuck the 'work offline' option under the sub menu 'Web Developer' of the File menu? It does not seem to me that the casual user will go there to look for this option.

Thanks,
Schalk

P.S. This is probably a completely separate 'bug' of sorts that might have been mentioned already somewhere else.

(In reply to comment #3)
> > This implementation is different to the way that Google Chrome has implemented
> > it
> 
> It's also different from Firefox 3.6, where we tried to "auto-detect" whether
> we have a network available.  The problem is that the auto-detection is wrong
> in some cases, and in particular that it sometimes decides there is no network
> when there could be one (e.g. auto-dial situations).  Note that returning false
> in that situation would be a spec violation; I don't know whether Chrome thus
> violates the spec.
> 
> I don't see how Chrome's implementation is more useful, by the way.  As the
> spec explicitly points out, just because there is a network link up doesn't
> mean there's internet connectivity.  So even if navigator.onLine is true you
> may still not be able to reach any particular site (or any site at all), and
> your code needs to deal with that.
Comment 6 Boris Zbarsky [:bz] 2011-05-04 13:15:17 PDT
No idea about the menu thing.  That's Windows-specific; on Mac it's just under the File menu.
Comment 7 Schalk Neethling 2011-05-04 13:44:47 PDT
Jip, on Windows it is not. This might be a bug then? Shall I file it?

Thanks,
Schalk

(In reply to comment #6)
> No idea about the menu thing.  That's Windows-specific; on Mac it's just under
> the File menu.
Comment 8 Boris Zbarsky [:bz] 2011-05-04 13:48:40 PDT
Like I said, no idea.  That'd be a Firefox issue, not a core issue...
Comment 9 Chad Woolley 2012-03-11 01:18:25 PST
(In reply to Boris Zbarsky (:bz) from comment #3)
> > This implementation is different to the way that Google Chrome has implemented
> > it
> 
> It's also different from Firefox 3.6, where we tried to "auto-detect"
> whether we have a network available.  The problem is that the auto-detection
> is wrong in some cases, and in particular that it sometimes decides there is
> no network when there could be one (e.g. auto-dial situations).  Note that
> returning false in that situation would be a spec violation; I don't know
> whether Chrome thus violates the spec.
> 
> I don't see how Chrome's implementation is more useful, by the way.  As the
> spec explicitly points out, just because there is a network link up doesn't
> mean there's internet connectivity.  So even if navigator.onLine is true you
> may still not be able to reach any particular site (or any site at all), and
> your code needs to deal with that.

I disagree with your assessment and the "worksforme" resolution of this bug.  Also, it appears that the window 'offline' event also follows this same behavior.

In effect, you are saying a client is "online" unless they've explicitly said they are "offline", even if there is no network connectivity.

This is different than the latest versions of Safari and Chrome, which will fire the offline event and return false for navigator.onLine if there is no network connectivity (Opera and IE behaves the same as Firefox/Mozilla).

This is just wrong, and I'll explain why.

Firstly, what percentage of clients in 2012 are "auto-dial"???  A statistically insignificant number.  Virtually all modern clients should be expected to have connectivity if a network interface is available.

Given that, Chrome's implementation is MUCH more useful for detecting online/offline state in an always-connected world.  All I have to do is listen for the "offline" event and (optionally) check the value of the navigator.onLine property .

Furthermore, this behavior breaks (completely as far as I know) the ability to make an "auto synchronizing" offline-aware application.

In other words, I want my app to do this:
- Detect when a client has lost network connectivity
- When loss of network connectivity happens, automatically fall back to storing user-submitted data to window.localStorage
- When network connectivity resumes, automatically submit locally-stored data to the server.

Here is an example application which implements this functionality:
http://miniapps.co.uk/blog/post/using-html5-localstorage-as-a-fallback-for-offline-form-submission
http://miniapps.co.uk/code/offlineform/

I know the argument for the current behavior is that the page MIGHT be cached, but I don't see how this is relevant to offline detection.  If the client has no network connectivity, and the page ISN'T cached, what should the application do?  It can't request the page anyway, but there's no way of knowing!  You have to go ahead and submit the request, and see if it fails to know if the user actually has network connectivity or not, then somehow recover from the failure, and act accordingly.  Wouldn't it be more efficient, not to mention simpler, to not have to submit a failed request to find out that you aren't actually "online"?

I see a comment from "boris" here suggesting that a random string be appended to the request URL in order to bypass a possible cache hit:

http://remysharp.com/2011/04/19/broken-offline-support/#comment-264211

I'm guessing that's bzbarsky from this ticket.  Again, that's a workaround, but wouldn't it be easier to KNOW if a request is going to fail rather than having to construct a special unique request URL each time you want to check whether or not network connectivity exists?

So, I'd like to respectfully request that this ticket be reconsidered.  The implementation of the spec which Chrome and Safari have decided upon is much more sensible and useful.

Thanks,
-- Chad
thewoolleyman@gmail.com
Comment 10 Ben Bucksch (:BenB) 2012-03-11 01:36:35 PST
Chad, as you have seen, there are other bugs that request the exact opposite than what you request. We formerly did have Firefox automatically switch to offline, but that caused major problems, because the detection wasn't reliable.

Current mobile devices are constantly switching networks, when WiFi connection is at the limit of range (in houses after 1-2 walls), or the device OS turns WiFi on/off after 1-2 minutes to save power, or when a 3G device moves around and loses connection and then reconnects to the base station constantly. The offline status would constantly go on and off. And, as said, often the online status is triggered. We're not in the analog modem world anymore where you're either online or offline.

Add to that that our implementation of the detection was far below its theoretical limits. This made this very troublesome and prevented people from browsing.

For the user, under the circumstances, its really better to manage the offline state explicitly. I agree with the INVALID/WONTFIX/WORKSFORME.
Comment 11 Chad Woolley 2012-03-11 01:38:31 PST
What about http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/index.html#idl-def-Connection ?  Is support for this planned?
Comment 12 Ben Bucksch (:BenB) 2012-03-11 01:42:09 PST
Please also note that the "online" mode wouldn't be reliable anyway for a webapp. It's a normal and common situation that I have an Ethernet card and wire, or WiFi connection to a router, but the DSL line is down. Most people's devices at home are not directly connected to the Internet, but via a router, so we do have "network", but not Internet, so we have no way of knowing whether the user has Internet access or not and we'd always return "online" per spec. So, your app needs to cope with the situation "browser says I'm online, but network doesn't actually" work anyway, and it wouldn't be exceptional, but the rule.
Comment 13 Ben Bucksch (:BenB) 2012-03-11 01:53:39 PST
Chad, as for the "Network Information API", it's not realistic to tell the speed of connection. One DSL provider sells me 20 MBit/s, and I have that at DSL level, but I normally get only 2 MBit/s of Internet connection, but that varies. Another advertizes the same and gives 17 MBit/s of actual Internet speed. And DSL is the most reliable, it ratio between advertized and actual can get far worse on heavily used cellphone networks or much worse on satellite links. Plus, upload speeds can vary widely, and very often they are the limiting factor, and the spec doesn't even mention that. This whole idea of "user is online and has 1MBit/s" is far to simplistic and simply not reflecting reality.

The fundamental flaw is that people are thinking of the Internet line as a telephone line, but it's not a switched network, but a packet network. One packet may arrive and the next might have problems, and at one moment you're fast and at the next you're slow. Network routes change, and your connection can change between WiFi and GSM, and suddenly you're in a hole and have no connection at all. It's not binary on/off.
Comment 14 Chad Woolley 2012-03-11 03:03:01 PDT
OK.  I respect your position, but it's very unfortunate that the major browser vendors are split on their interpretation of this portion of the specification.

In my opinion, there should be two independent sets of "online/offline" flags/events:

* One for user-indicated (as Mozilla/Firefox/IE/Opera have interpreted the spec)
* ...and one for best-guess auto-detected (as Chrome/Safari/Webkit have interpreted the spec).  This would be, as you said, implicitly unreliable and subject to very frequent changes, but as I have pointed out, very useful in many scenarios.

This solution would avoid this argument, and allow the application to decide which is the most appropriate one to use.

Thanks for your feedback.
-- Chad
Comment 15 Ben Bucksch (:BenB) 2012-03-11 03:13:41 PDT
Chad, the unreliable flag wouldn't serve any purpose. If may show offline, even though you're online, and it often shows online when though you're offline. How would you change your app based on that? If you also build automatisms in your app, they are likely to get into the way of the user more than they help. This is what actually happened and why we changed. (And even if you build your webapp to cope with the fact that the flag may be wrong, most webapps won't.)
If we could find out reliably, I'd agree with you. But we can't, and that hurts more than it helps.
Comment 16 Chad Woolley 2012-03-11 12:49:09 PDT
Ben,

You're very likely right.  Which means the Chrome and Webkit folks are wrong - err, of a differing opinion ;)  

After thinking about what you've said, obviously any solid app must handle unexpected connection failures gracefully, regardless of whether the browser told them the client was online or not.  And, given that, I can understand why you would believe that it's pointless for the browser to even attempt to automatically detect or indicate online/offline status.

But of course I'll have to find out for myself ;)  

Thanks again for discussing and explaining your position.

-- Chad
Comment 17 Jonas Sicking (:sicking) 2012-10-03 16:15:18 PDT
Let me know if you want me to comment in bug 654579 instead of here.

It seems really bad to me that we're only switching navigator.onLine to false when the user selects "offline mode" in the firefox menu.

The spec says in the normative text:

  The navigator.onLine attribute must return false if the user agent will not
  contact the network when the user follows links or when a script requests a
  remote page (or knows that such an attempt would fail), and must return true
  otherwise.

The "or knows that such an attempt would fail" text is in parenthesis, but it's still normative as far as I can tell. When the OS has no internet connection and no "auto-dial" feature, we definitely know that any network connections would fail.

99% of our users never use the "work offline" menu item [1] so from websites point of view that feature is pretty uninteresting.

Optimizing for the auto-dial scenario seems like the wrong optimization in this day and age. I'd much rather that we are wrong in cases when there is auto-dial available, than in cases when the user is in airplane mode, has no wifi connection or otherwise are currently disconnected from the internet.

As things stand now the navigator.onLine property, along with the online/offline events are effectively not implemented in Gecko. That's bad and likely affects both websites and users. I know that gmail for example deal very poorly with me temporarily loosing my wifi connection. I bet this bug plays a part there.

At the very least we need to fix this for B2G. But I would say that we need to fix this for Firefox desktop just as much.

If we want something which indicates the "user has chosen the 'work offline' menu item" then I think we should introduce a separate feature for that. But given [1] I suspect that's not worth it.

[1] https://blog.mozilla.org/ux/2012/06/firefox-heatmap-study-2012-results-are-in/
Comment 18 Mounir Lamouri (:mounir) 2012-10-04 02:24:10 PDT
(In reply to Jonas Sicking (:sicking) from comment #17)
> If we want something which indicates the "user has chosen the 'work offline'
> menu item" then I think we should introduce a separate feature for that. But
> given [1] I suspect that's not worth it.

I think we can simply mark the user offline when he/she is actually offline or has selected the work offline menu item.
Comment 19 Jonas Sicking (:sicking) 2012-10-04 08:04:43 PDT
*** Bug 796978 has been marked as a duplicate of this bug. ***
Comment 20 Jonas Sicking (:sicking) 2012-10-04 08:13:34 PDT
That sounds like a good idea to me yeah.
Comment 21 Jonas Sicking (:sicking) 2012-10-04 10:38:37 PDT
Clearing nom and letting this bug just cover desktop.
Comment 22 Kev Needham [:kev] 2013-01-08 00:58:45 PST
*** Bug 827322 has been marked as a duplicate of this bug. ***
Comment 23 Robert Kieffer 2013-01-10 11:35:46 PST
I agree with Jonas' points in Comment 17

For real-world usage, this feature is effectively broken.  Not only is "work offline" mode little used, as a web app developer what I care most about is the browsers connectivity status.  I.e. _can I communicate with the server_?  "work offline" mode certainly plays a [small] part in the answer, but in and of itself is of little user.  navigator.onLine should reflect the status of the devices network connectivity, to the best of our (the browser's) knowledge.

Two specific use cases I've worked on where this has come up:
- Facebook Chat needs to know when comet connections can reasonably be expected to succeed.  This affects both the UI ("Network currently unavailable"), and the logic around trying to re-establish the connection ("Should the backoff delay be increased? When is the soonest time we should attempt to reconnect?")
- Facebook's client logging framework needs to know when it can ship buffered log data to the server. Making a request when the network is known to be down is pointless; and addressing cases where requests fail is problematic because of how it tends to introduce data duplication issues.  Having a (reasonably) reliable indicator of network status does a lot to minimize the issues here.
Comment 24 Joris Debonnet 2013-02-26 08:37:44 PST
I hope the navigator.onLine status can be brought back to Firefox soon. I don't really understand the arguments against it. 

It is an unreliable feature, but why is that a reason not to implement it at all? It's like saying 10 years ago (or even now): don't use CSS, because it's unreliable, it can render differently in different browsers. My point is: even if it's not 100% reliable, it is still helpful. 

People may go online and offline many times due to switching networks or being on a buggy connection. But I don't really see that as a problem either; that's precisely what it's useful for. Even if it happens multiple times a minute, then I do in fact want my offline- and online- event handler to be fired. I strongly believe that that is what most web developers expect from this feature. 

As I understand it, the reluctance comes from the fact that the online/offline status can not always be determined 100% correctly: if it shows 'true', there may not in fact be an internet connection. 
But if right now, it simply always shows as online (except in a case barely anyone uses), then surely this situation is worse still :)
Comment 25 Boris Zbarsky [:bz] 2013-02-26 08:40:17 PST
> if it shows 'true', there may not in fact be an internet connection. 

And vice versa: if it shows 'false' there may in fact be an internet connection.
Comment 26 Joris Debonnet 2013-02-26 08:59:19 PST
But under what conditions would that happen? Has anyone ever checked what Webkit browsers report under the same conditions? 

If they handle it better, I guess we'd need to figure out how they are avoiding those false negatives.
If they just do it the same way, I'd say go along with it, because developers already need to take those conditions into account for Webkit browsers anyway - especially since they are so omnipresent on mobile devices. Also, even with the (likely rare) false negatives, it's still more useful than a boolean that always shows true. 

'Offline Mode' is only used by people that know something about websites anyway - it's even under the Web Developer submenu (on Windows), so I would consider it a debug feature only.
Comment 27 Boris Zbarsky [:bz] 2013-02-26 09:17:00 PST
> But under what conditions would that happen?

When trying to connect to the network will start up the internet connection (which until that point is down).  This can certainly happen on Windows, and is the reason that offline state is no longer tied to what the OS reports as "offline" (which it used to be, but it meant that for a number of users they were always considered offline until some other application tried to use the network).

> Has anyone ever checked what Webkit browsers report under the same conditions? 

Last I checked, they report the user as offline.

> because developers already need to take those conditions into account

Except they don't.  Last I checked, pages that used offline status were broken for such users in WebKit browsers.
Comment 28 Joris Debonnet 2013-02-26 09:36:34 PST
> When trying to connect to the network

Under normal circumstances, this should only be a temporary situation, right? As long as the status is 'online' after a while, there isn't really a problem for most applications. It might have been erroneously marked 'offline' for a while, but whatever synchronizations it needs to do, it will attempt as soon as we report 'online' again. 

> Except they don't.  Last I checked, pages that used offline status were broken for such users in WebKit browsers.

I guess I stated above that it may not be a problem anyway - but even if it is, then I suppose those developers will need to update their code to handle it. Honestly: if they are using the status flag, they're doing it for those browsers that support it. Whether Firefox starts supporting the same functionality, it is not going to make their code any better or worse. 

You might wonder what's the point of the property if developers need to support all cases anyway, but my answer would be that using the property will give a snappier response than their own support code, which may only check for connectivity every 5 seconds or so, and only report a disconnection after a timeout. 

I just noticed with a simple test that not only Webkit browsers support it: IE8 and IE9 do, too. So there don't seem to be any major browsers beside Firefox that do not have sensible support for navigator.onLine.
Comment 29 Boris Zbarsky [:bz] 2013-02-26 09:41:44 PST
> Under normal circumstances, this should only be a temporary situation, right?

"temporary" until the user tries to use some other website, yes.

So if you have a calendar app and the user starts their browser to resync the calendar... it won't.
Comment 30 Robert Kieffer 2013-02-26 10:18:41 PST
@Boris - the navigator.onLine spec makes it clear that false negatives such as those you allude to are not allowed.  If there's any ambiguity as to how the client will behave when a network request is made, the onLine property must return "true".
Comment 31 Boris Zbarsky [:bz] 2013-02-26 10:22:13 PST
The point is on Windows there's no way to tell that without actually trying to make a network request, which last I checked browsers didn't do.
Comment 32 Ben Bucksch (:BenB) 2013-02-26 10:23:45 PST
Robert, and with *that* standard, there's no other way than to always return true. See comment 10 and 12 for reasons why we cannot be sure.
Comment 33 (not reading bugmail) Nick Desaulniers [:\n] 2013-04-22 12:58:29 PDT
What's the point of checking the client's online status when the data sources, which you may have multiple of, may be offline?  If your client is connected, but every source they would pull in data from is offline, what does being online really mean?

You can't know your request will succeed until you make it.
Comment 34 Joris Debonnet 2013-04-22 13:49:02 PDT
The point is that the feedback is much faster. 

The user will be notified quicker that there may be a problem with the connection, rather than only finding out when they try using the web application, where the request first has to time out before finally causing an error to appear.
Comment 35 Nathan Phillip Brink (binki) 2013-06-11 12:22:24 PDT
Probably completely irrelevant, but I do think that having some sort of event fire when the OS’s network interface state changes at all would be useful. In windows, is it possible to detect when an interface changes state from “Identifying” to “Internet Access”? It would be nice if a webapp could get the “online” event in this case even if navigator.onLine is not being updated because, as mentioned in comment 28, the important thing is to let webapps know when it is a good time to try to reestablish connections to supplement their polling mechanisms.

This web API doesn’t make much sense on the desktop, with the automatic dialup example and isolated LAN scenarios. The only way to detect “onlineness” for certain is to make a request to a known good host, like iOS does. Since the offline mode switch is so inaccessible to people, maybe it could be controlled by Windows 8’s “Airplane mode” ( http://windows.microsoft.com/en-us/windows-8/what-is-airplane-mode ). This resembles many mobile OSes’ “Airplane mode” and appears to the user to essentially be an OS-wide “offline mode”. Unfortunatley, “Airplane mode” does not turn off ethernet AFAIK and users can still reenable individual wireless network interfaces. But I hope that, in most cases, “Airplane mode” indicates that the user wants to limit network use anyways... and one can always click through the offline mode error to disable the mode.

Sorry for the bugspam. This navigator.onLine API is asking for desktop browsers to do impossible things while making sense in mobile environments where the OS can guarantee no false-positives ;-). I would like an API which fires events indicating that “the local host’s network configuration has changed in such a way that the browser advises apps to re-check if they can make successful web requests/connections”. Maybe this API can be abused (by sending spurious “online” events) to provide something like that, most likely this is the wrong place to request that sort of change :-/.
Comment 36 Ben Bucksch (:BenB) 2013-06-11 17:50:30 PDT
> having some sort of event fire when the OS’s network interface state changes at all would
> be useful ... let webapps know when it is a good time to try to reestablish connections to
> supplement their polling mechanisms.

Agreed on that one
Comment 37 Kohei Yoshino [:kohei] 2014-03-23 18:05:34 PDT
Thunderbird (on Mac) can change the online/offline status seamlessly when I plug in/out my Ethernet cable. I wonder why Firefox cannot fire the online/offline events and change the navigator.onLine vaule?
Comment 38 Boris Zbarsky [:bz] 2014-03-23 19:31:30 PDT
Firefox used to have that behavior (which is in fact implemented in core code).  It actually gets the state wrong often enough, and that was a was a big enough problem for a web browser, that we dropped it.  You may want to search for the bug that did that and read the details.
Comment 39 :Ehsan Akhgari (busy, don't ask for review please) 2014-03-23 19:34:14 PDT
(In reply to comment #38)
> Firefox used to have that behavior (which is in fact implemented in core code).
>  It actually gets the state wrong often enough, and that was a was a big enough
> problem for a web browser, that we dropped it.  You may want to search for the
> bug that did that and read the details.

That's bug 620472, FWIW.
Comment 40 Kohei Yoshino [:kohei] 2014-03-23 19:50:49 PDT
Thanks for the pointer. I envy Chrome and Safari where the auto detection is enabled.
Comment 41 :Ehsan Akhgari (busy, don't ask for review please) 2014-03-23 20:14:10 PDT
(In reply to comment #40)
> Thanks for the pointer. I envy Chrome and Safari where the auto detection is
> enabled.

If you would like to help, it would be interesting to turn that pref on and report any issues with it on your platform.  That is a first step for this to be fixed some day.
Comment 42 Kohei Yoshino [:kohei] 2014-03-23 20:26:25 PDT
network.manage-offline-status=true works fine with me. Firefox Aurora 30 on OS X 10.9.2. I'm developing a Web app with offline support. https://github.com/kyoshino/bzdeck/issues/32
Comment 43 Ben Bucksch (:BenB) 2014-03-24 07:03:52 PDT
comment 35:
> having some sort of event fire when the OS’s network interface state changes at all would
> be useful ... let webapps know when it is a good time to try to reestablish connections to
> supplement their polling mechanisms.

That's bug 756364, apparently.
Comment 44 Boris Zbarsky [:bz] 2014-08-27 07:10:38 PDT
*** Bug 1058950 has been marked as a duplicate of this bug. ***
Comment 45 Roman R. 2014-08-30 08:40:59 PDT
I've noticed that Chrome detects loss of connection MUCH less reliably than IE (v10). So please don't emulate the way Chrome works in this regard.
Comment 46 Roman R. 2014-08-30 08:45:30 PDT
(In reply to Roman R. from comment #45)
> I've noticed that Chrome detects loss of connection MUCH less reliably than
> IE (v10). So please don't emulate the way Chrome works in this regard.

I will elaborate on that. Both browsers do it well when I test this ability by manually disconnecting from a WiFi connection. However, when I lost connection without my intention (due to whatever happened with one or more of these modem/router, signal booster, adapter, networks lines outside my home, etc.), IE detected disconnections MUCH more accurately than Chrome.
Comment 47 Andrew Sutherland [:asuth] 2014-10-21 12:42:44 PDT
*** Bug 783516 has been marked as a duplicate of this bug. ***
Comment 48 Valentin Gosu [:valentin] 2015-02-11 08:29:35 PST
So, given that we'd like to make some progress on this bug, I did a little research regarding Chrome and IE's behaviour.

I tested on Windows8.1 and Linux
It seems Chrome has navigator.onLine set to true as long as there's at least one interface with an IP address (it ignores loopback).
At one point I had an extra interface with just a link-local IPv6 address, and it was enough to keep Chrome showing onLine as true, even though it had no connectivity.
Also, on my windows machine, VMware created some extra interfaces which made Chrome show nav.onLine as always true.

IE11 is slightly smarter. Somehow it was able to ignore the interfaces created by VMware and reliably flipped navigator.onLine when I switched the WiFi off. My guess is that is responds to the actual hardware devices, instead of the virtual adapters having an IP address.
It seems that connectivity isn't taken into account for IE either, as connecting to a router with no internet connection, or to one that has a captive portal still makes nav.onLine show up as true.

So, adding some logic to detect interfaces with IP addresses would probably improve this situation somewhat. However, this API is flawed slightly, as it doesn't give you much information about the actual connectivity status, and apps have to roll their own logic anyway.

Also, note that in Firefox, the network.manage-offline-status pref doesn't seem to do anything anymore, and can probably be removed.
Comment 49 Daniel Stenberg [:bagder] 2015-02-11 09:45:32 PST
(In reply to Valentin Gosu [:valentin] from comment #48)

> It seems Chrome has navigator.onLine set to true as long as there's at least
> one interface with an IP address (it ignores loopback).

So in reality that makes the value fairly useless on modern desktops since most users are bound to have at least one non-local interface.

And also, doesn't it mean that Firefox's behavior is almost identical to Chrome's since basically it never gets set to false?

> So, adding some logic to detect interfaces with IP addresses would probably improve this situation somewhat.

it is also a slippery slope since even local addresses can be used to tunnel to somewhere else...
Comment 50 Jonas Sicking (:sicking) 2015-02-11 12:50:41 PST
(In reply to Valentin Gosu [:valentin] from comment #48)
> So, given that we'd like to make some progress on this bug, I did a little
> research regarding Chrome and IE's behaviour.
> 
> I tested on Windows8.1 and Linux
> It seems Chrome has navigator.onLine set to true as long as there's at least
> one interface with an IP address (it ignores loopback).

Were you able to get into any situations where Chrome shows navigator.onLine as false, but where the user is actually connected to the internet, and where a webpage could actually make a network request and have it succeed?

I've been told that that can happen, but sadly I didn't receive any more details.

> It seems that connectivity isn't taken into account for IE either, as
> connecting to a router with no internet connection, or to one that has a
> captive portal still makes nav.onLine show up as true.

It'd be pretty tricky to do that right. For example, there might be servers connected to the same router which serve websites. Or there might be reachability issues with the particular server which the browser would use to do "online testing", but the rest of the internet is perfectly reachable.

A problem is that false negative seems potentially more harmful than a false positive. But it's definitely something worth continuing to look at.

> So, adding some logic to detect interfaces with IP addresses would probably
> improve this situation somewhat. However, this API is flawed slightly, as it
> doesn't give you much information about the actual connectivity status, and
> apps have to roll their own logic anyway.

Yeah. I think websites will have to keep doing that until we add an API which allow getting notified about reachability of a particular server. But clearly that's a separate API than navigator.onLine.
Comment 51 Valentin Gosu [:valentin] 2015-02-11 14:03:36 PST
(In reply to Jonas Sicking (:sicking) from comment #50)
> > It seems Chrome has navigator.onLine set to true as long as there's at least
> > one interface with an IP address (it ignores loopback).
> 
> Were you able to get into any situations where Chrome shows navigator.onLine
> as false, but where the user is actually connected to the internet, and
> where a webpage could actually make a network request and have it succeed?
> 
> I've been told that that can happen, but sadly I didn't receive any more
> details.
> 

It's possible that there are other similar bugs, but the one I found regarding this issue has been fixed: https://code.google.com/p/chromium/issues/detail?id=124069

> > It seems that connectivity isn't taken into account for IE either, as
> > connecting to a router with no internet connection, or to one that has a
> > captive portal still makes nav.onLine show up as true.
> 
> It'd be pretty tricky to do that right. For example, there might be servers
> connected to the same router which serve websites. Or there might be
> reachability issues with the particular server which the browser would use
> to do "online testing", but the rest of the internet is perfectly reachable.
> 
> A problem is that false negative seems potentially more harmful than a false
> positive. But it's definitely something worth continuing to look at.
> 

Yes, we should do everything we can to avoid false negatives, but it's possible that we're being to conservative at the moment (always true).
Comment 52 Jonas Sicking (:sicking) 2015-02-11 14:25:52 PST
(In reply to Valentin Gosu [:valentin] from comment #51)
> Yes, we should do everything we can to avoid false negatives, but it's
> possible that we're being to conservative at the moment (always true).

Absolutely! I'm fully in support of more aggressively returning 'false'. Especially since our current level of aggressiveness is essentially "never return false" :).

I was only asking to understand if Chrome had some especially clever tricks up their sleeve, but it sounds like that wasn't the case.

So yeah, prodding for network interfaces with an IP number sounds good.

I think the only concern would be systems with a dialup modem which connects to the internet "on demand" when a network connection is attempted. IIRC that was one of the big arguments for why we haven't fixed this bug in the past.
Comment 53 Valentin Gosu [:valentin] 2015-02-11 14:37:07 PST
(In reply to Jonas Sicking (:sicking) from comment #52)
> I think the only concern would be systems with a dialup modem which connects
> to the internet "on demand" when a network connection is attempted. IIRC
> that was one of the big arguments for why we haven't fixed this bug in the
> past.

How about if we ever used dial up, keep .onLine always true, else check for interfaces with IPs and act accordingly?
Comment 54 Jonas Sicking (:sicking) 2015-02-11 14:42:42 PST
Sounds good. Only caveat is: Is there a risk that the user won't be able to use the web after having installed firefox for the first time?
Comment 55 Valentin Gosu [:valentin] 2015-02-11 14:49:58 PST
AFAICT offline-mode isn't dependent on navigator.onLine. So for someone with a dial-up modem, when first installing Firefox, navigator.onLine would be false until the user loads a page for the first time and the dial up connection is triggered. At least I think that would be the case. Daniel/HonzaB might know more about it.
Comment 56 Jonas Sicking (:sicking) 2015-02-11 15:01:35 PST
Ah! Right! Good point. That resolves my concern.
Comment 57 Daniel Stenberg [:bagder] 2015-02-12 00:37:35 PST
(assuming we consider network.manage-offline-status obsolete and subject for future removal)

What isn't already working like this?

This bug report implies that we do something wrong now, but isn't navigator.online basically saying we're online until forcibly ("Work Offline" checked) told we're not?

Firefox on Windows (https://mxr.mozilla.org/mozilla-central/source/netwerk/system/win32/nsNotifyAddrListener.cpp#441) basically detects a total lack of network "adapters" and will only set network down in that case.

Firefox on Mac (https://mxr.mozilla.org/mozilla-central/source/netwerk/system/mac/nsNetworkLinkService.mm#273) uses the operating system's functionality and if it says there is no "reachability" on the interfaces it can be set offline - should be rare. I believe "reachability" basically means being able to send out IP traffic.

Firefox on Linux (https://mxr.mozilla.org/mozilla-central/source/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp#99) never sets offline.
Comment 58 Jason Duell [:jduell] (needinfo? me) 2015-02-12 17:08:36 PST
So at this point guessing whether we're offline is not 100% foolproof.  This means that 

1) We shouldn't treat that guess as certain, so we shouldn't set IOService.offline, which basically cripples the browser incorrectly when we have a false negative guess.  That was a leading source of complaints and the reason we currently have autodetection disabled on desktop (see bug 620472 comment 17)

2) The main use case once we'll have remaining is Navigator.online.  Apps that check it may still need to do their own polling to find out if the connectivity they want is really available.  Ideally, we can eliminate false negatives, which would mean that apps could pause their pings when we're marked offline.  But even if we can't do that, we will at least more often provide a transition on Navigator.online (and fire the 'online' or 'offline' DOM events), which will tell apps that this is a good time to try a ping, i.e. apps should detect sooner when the network is back up.

3) We want to see exactly what Chromium code does and make sure we're at least as accurate.  Valentin says that IE seems to do a better job than Chrome at filtering out network interfaces that are for virtual machines, or otherwise not 'real' interfaces.

4) Ideally, whenever we notice that the network config has changed, we could fire some event to the DOM to let apps know it's a good time to ping.  I.e. even if navigator.online = true, we'd fire another 'online' event (or some new event).  I've asked Jonas if that's something we could get away with (it's not the spec'd HTML5 behavior, which says online only gets fired when we change from false->true).

5) We want telemetry on this.  Specifically 1) what % of sessions experience detecting that we're offline, and 2) how often we wind up doing network traffic successfully when we thought we were offline (i.e our false negative rate).  We should also use that information to force navigator.online to be 'true' when that happens.

6) Firefox OS has its own NetworkManager that does offline detection.  We should see how it works and whether we can move that logic into nsIOService, so we could share code with our Linux desktops and/or Fennec browser.

Code changes:

No longer have our network detection algorithm set IOService.offline=true when it guesses we're disconnected.  Instead have it set some new variable in the IOService, like nsIIOService.IsNetworkReachable that is documented to be a prediction, not a sure thing (but a good enough guess to set Navigator.online with).
And have Navigator.online be offline if either NS_IsOffline() or !nsIIOService.IsNetworkReachable.

For now isNetworkReachable is probably just a matter of looking through the network interfaces and returning true if 1) there are any, and maybe 2) if they aren't all filtered out for being virtual ones and/or ones w/o an IP address, etc.  (And any other checks that the Chromium code does or we can reverse engineer from IE).  And it would be great to have a way to force isNetworkReachable (maybe just make it writable?) so we can override it if we discover we're doing network traffic despite thinking we're offline.


> Firefox on Linux (https://mxr.mozilla.org/mozilla-central/source/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp#99) never sets offline.

Is that really true?  The code you're pointing to is about network change events, not offline.  And it sounds like Fennec at least has seen this work in the past (bug 729951, which has regressed: see bug 1132693).  Maybe they did something android-specific?
Comment 59 Daniel Stenberg [:bagder] 2015-02-16 03:16:52 PST
(In reply to Jason Duell [:jduell] (needinfo? me) from comment #58)

> Is that really true?  The code you're pointing to is about network change
> events, not offline.  And it sounds like Fennec at least has seen this work
> in the past (bug 729951, which has regressed: see bug 1132693).  Maybe they
> did something android-specific?

Fennec has its own logic, the "Linux" backend for that is only for Linux desktop and FxOS.
Comment 61 Joe Pollock 2015-03-29 14:39:44 PDT
My head is spinning a bit from reading this thread. It appears, as usual, that the only issues which are simple are the ones I don't know much about.

I just want to add an end user perspective here.

Many times, I turn on my notebook when my wifi router is still off. Firefox (36 Linux) gets started by KDE session restore (as desired). Later, I get up and turn the router/wifi on (it's in another part of the house).

What happens in this scenario is that Firefox has set itself into Offline Mode (probably because my local home page has a link to an online gif in it).

Now, when I try to access any online link, it tells me I'm offline and that I should try again. When I click on Try Again, it comes back with the same message and I have to click on Try Again a second time to get it to actually try to go to the Internet and start working. If I'm still really offline, I get the normal message about can't locate server, etc., but I'm still in "Online Mode" where I want to be.

So, not only is it telling me I'm offline (when I know the router/Internet is on), but it's making me tell it twice before it will actually have a look at the Internet and see for itself.

What I would like to have it do would be to skip Offline Mode completely and either get me my page or tell me it can't - the way it does now after I click on Try Again twice.

I already have Firefox network.manage-offline-status set to false and, as noted in other comments here, it doesn't appear to do anything.

---

Once in a great while, I run across a webpage that just won't finish loading (not a Firefox issue at all) and I want to use the Print dialog. In this case, even if I have stopped Firefox from continuing to load the page, the Print dialog starts it up again and hangs. In this case, I cancel the print, select Offline Mode, and print again and the print proceeds as desired. (Then, I immediately turn Offline Mode back off again.)

This is the only case where Offline Mode is valuable to me and why I don't want it to go away completely. But I do want the part where Firefox goes into Offline Mode automatically to go away or, at least, allow me to disable this behavior with a config parameter which actually works.

Seeing yesterday's weather, etc. on my screen because Firefox has saved it for Offline use is not a benefit to me, it's a confusing distraction.
Comment 62 Daniel Stenberg [:bagder] 2015-03-30 04:46:04 PDT
(In reply to Joe Pollock from comment #61)

> Many times, I turn on my notebook when my wifi router is still off. Firefox
> (36 Linux) gets started by KDE session restore (as desired). Later, I get up
> and turn the router/wifi on (it's in another part of the house).
> 
> What happens in this scenario is that Firefox has set itself into Offline
> Mode (probably because my local home page has a link to an online gif in it).

Thanks Joe,

Let me first tell you that I understand that it may be hard to keep track of every tiny little detail here, but the good part is that we're at least working hard at cleaning this (the general online/offline situation) up and making sure it will start to make sense going forward.

I cannot repeat your problem as described, not with Nightly and not with Firefox 36 and I tried several variations of the procedure. Firefox on Linux really does not (normally) set itself offline without the manage-offline-status set true and I'm really at loss how it manages to do that for you.

Firefox does not (ever) set itself to offline just because it fails to "download a gif" or similar. It _can_ be told to set itself offline when it finds itself without a working network interface, but only if asked to and it doesn't do that at all on Linux.

The only reason Firefox on Linux can start up and claim to be in offline mode (without said pref enabled or by user-choice) that I can think of is if nsIOService fails early on and never sets itself as online. And that too seems unlikely. I'm really curious to figure out what's hitting you!

If you have a step-by-step procedure on how to trigger this problem, please tell me!

> What I would like to have it do would be to skip Offline Mode completely and
> either get me my page or tell me it can't - the way it does now after I
> click on Try Again twice.

That's roughly where we are heading. With bug 1134596 getting done, Firefox will be able detect an "offline" state (== lack of any network that is UP) but it won't use that state to prevent further network operations (unless you ask for it).

> I already have Firefox network.manage-offline-status set to false and, as
> noted in other comments here, it doesn't appear to do anything.

It certainly does something, but not on Linux in version 36...
Comment 63 Joe Pollock 2015-03-30 16:18:12 PDT
Just tried a couple of things to recreate the problem and could not. I will post here if I do figure out exactly how to recreate it. Thanks for your detailed reply.
Comment 64 :Ehsan Akhgari (busy, don't ask for review please) 2015-06-10 08:13:08 PDT
Daniel, what is the status of this bug?  Are you still working on it?  This is going to hurt us in any service worker demo when people want to demo that a website still works when you're offline (see bug 1157943.)
Comment 65 Valentin Gosu [:valentin] 2015-06-10 08:29:22 PDT
For the demo, you can set network.manage-offline-status = true
I haven't tested it works with service workers, but it should :)
Note: detection doesn't work on Linux.

Actually, I think we could just set it to true already:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=afeebf2b3c60
Daniel, what do you think?
Comment 66 :Ehsan Akhgari (busy, don't ask for review please) 2015-06-10 13:38:25 PDT
(In reply to Valentin Gosu [:valentin] from comment #65)
> For the demo, you can set network.manage-offline-status = true

Sorry for not being more clear.  I wasn't talking about a specific demo.  I was talking about the scenario of "Firefox has shipped service workers, let's see if Trained to Thrill [1] works offline, disconnect wifi, oops, it doesn't work offline."  :-)

[1] Trained to Thrill is a very high profile demo of the service worker technology.  <https://jakearchibald.github.io/trained-to-thrill/>

> I haven't tested it works with service workers, but it should :)
> Note: detection doesn't work on Linux.
> 
> Actually, I think we could just set it to true already:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=afeebf2b3c60
> Daniel, what do you think?

What does that pref do, out of curiosity?
Comment 67 Valentin Gosu [:valentin] 2015-06-10 13:40:48 PDT
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #66)
> 
> What does that pref do, out of curiosity?

If set to true, navigator.onLine will change according to network connectivity.
Comment 68 Valentin Gosu [:valentin] 2015-06-10 15:03:39 PDT
Created attachment 8620630 [details] [diff] [review]
imported patch _enable_network_detection.patch
Comment 69 Jason Duell [:jduell] (needinfo? me) 2015-06-11 00:11:56 PDT
Comment on attachment 8620630 [details] [diff] [review]
imported patch _enable_network_detection.patch

Review of attachment 8620630 [details] [diff] [review]:
-----------------------------------------------------------------

:bagder, you know this better than me.  Are we ready to pref-on?
Comment 70 Daniel Stenberg [:bagder] 2015-06-11 00:20:52 PDT
I'm +1 on enabling this. We need to make sure it works and we need to try it out in the wild to get to know this - as hardly anyone will do this prefs change manually.
Comment 71 Andrew Overholt [:overholt] 2015-06-11 07:51:32 PDT
(In reply to Valentin Gosu [:valentin] from comment #65)
> Note: detection doesn't work on Linux.

Is there a followup bug for getting this to work on Linux?
Comment 72 Kohei Yoshino [:kohei] 2015-06-11 07:57:46 PDT
I'd like to see Bug 756364 solved as well.
Comment 74 Daniel Stenberg [:bagder] 2015-06-11 12:22:30 PDT
(In reply to Kohei Yoshino [:kohei] from comment #72)
> I'd like to see Bug 756364 solved as well.

With this change just landed, is there anything left to fix for bug 756364 that you know of?
Comment 75 Daniel Stenberg [:bagder] 2015-06-11 12:30:26 PDT
(In reply to Andrew Overholt [:overholt] from comment #71)

> Is there a followup bug for getting this to work on Linux?

There is now! Bug 1173931
Comment 76 Kohei Yoshino [:kohei] 2015-06-11 12:49:57 PDT
I'm on OS X, have enabled the pref, but somehow the detection is not working. navigator.onLine is still true and the offline event is not fired when I turn Wi-Fi off, though Thunderbird (31.7.0) detects well. I thought it was working before (comment 42). Regressed at some point?
Comment 77 Wes Kocher (:KWierso) 2015-06-11 17:13:28 PDT
https://hg.mozilla.org/mozilla-central/rev/fc9297fa66aa
Comment 78 nevraeka 2015-06-12 04:24:36 PDT
What versions of Nightly & Standard Firefox can we expect this to work with. Currently on the mac v.41.0a1 of Nightly does not reflect changes which is why I ask. Do I need to set a flag? Thanks in advance
Comment 79 Valentin Gosu [:valentin] 2015-06-12 04:32:07 PDT
(In reply to nevraeka from comment #78)
> What versions of Nightly & Standard Firefox can we expect this to work with.
> Currently on the mac v.41.0a1 of Nightly does not reflect changes which is
> why I ask. Do I need to set a flag? Thanks in advance

Starting with today's nightly this should work.
On older build, you need to set network.manage-offline-status to true in about:config.
I tested on Firefox 38.0.5 on OS X, and after flipping the pref navigator.onLine and window.ononline/window.onoffline work as they should.
Comment 80 nevraeka 2015-06-12 04:46:45 PDT
Thank you Valentin. I'll check it out in tomorrows build
Comment 81 nevraeka 2015-06-16 10:25:02 PDT
Valentin- navigator.onLine still always returns true (testing in nightly v41.0.a1)
Comment 82 nevraeka 2015-06-16 10:28:05 PDT
Only when I set the appropriate flag does it work correctly
Comment 83 Kohei Yoshino [:kohei] 2015-06-16 11:18:14 PDT
Same here, the network.manage-offline-status pref is still false by default on the latest Nightly build at least for OS X.
Comment 84 Valentin Gosu [:valentin] 2015-06-19 11:05:08 PDT
Created attachment 8624839 [details] [diff] [review]
Set the network.manage-offline-status to true for desktop
Comment 85 Valentin Gosu [:valentin] 2015-06-19 11:06:21 PDT
Comment on attachment 8620630 [details] [diff] [review]
imported patch _enable_network_detection.patch

Given that each platform redefines this pref, we only needed to flip it in firefox.js
Comment 88 Carsten Book [:Tomcat] 2015-06-22 05:11:40 PDT
https://hg.mozilla.org/mozilla-central/rev/51168e14388c
Comment 89 Jean-Yves Perrier [:teoli] 2015-06-30 15:27:39 PDT
Doc updated: https://developer.mozilla.org/en-US/Firefox/Releases/41#InterfacesAPIsDOM
and
https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine

Release Note Request (optional, but appreciated)
[Why is this notable]: The previous behavior changed and has a large impact on offline detection.
[Suggested wording]: On OS X and Windows, Navigator.onLine now varies with actual internet connectivity. Previously it was only affected by the 'Work offline' option.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine
Comment 90 Ritu Kothari (:ritu) 2015-07-01 17:47:13 PDT
This was added to Firefox 41.0a2 release notes.
Comment 91 nevraeka 2015-07-02 07:24:43 PDT
Tested in 41.0a2. It's working now. Great job
Comment 92 :Ehsan Akhgari (busy, don't ask for review please) 2015-07-21 14:57:02 PDT
*** Bug 1157943 has been marked as a duplicate of this bug. ***
Comment 93 Derek Moore 2015-10-07 08:28:27 PDT
Why is this bug marked as RESOLVED when there is no fix for modern Linux desktops???

Over in the GNOME bugzilla, there is an issue where improvements to online detection functionality are being considered (between D-Bus, NetworkManager, and GNOME Shell):

https://bugzilla.gnome.org/show_bug.cgi?id=738694
Comment 94 Joe Pollock 2015-10-07 09:45:00 PDT
@Derek Moore - See bug 1173931. It may be relevant.

https://bugzilla.mozilla.org/show_bug.cgi?id=1173931
Comment 95 nackd 2016-01-18 07:44:21 PST
Posting this using 43.0.4. I can confirm this is *NOT* fixed on Linux.
Comment 96 Daniel Stenberg [:bagder] 2016-01-18 15:18:39 PST
(In reply to nackd from comment #95)
> Posting this using 43.0.4. I can confirm this is *NOT* fixed on Linux.

Can you please elaborate with details? What do you run, what prefs have you altered, what do you do, what do you see?
Comment 97 nackd 2016-01-19 02:50:41 PST
With no network connection active, I start Firefox with a new user profile, open the "Web Console" and navigator.onLine returns true. The result is the same if I have a connection active when I open Firefox and deactivate it before checking navigator.onLine.

This is an up-to-date Arch Linux install, 4.3.3 kernel, netctl, KDE. NetworkManager is installed because of dependencies, but I don't use it at the moment and the daemon is not running.
Comment 98 Daniel Stenberg [:bagder] 2016-01-19 05:59:59 PST
Please create a new bug to deal with this properly. Re-opening such an old bug with so much history and legacy (and is originally set for windows) is not a good idea and only risk derailing us into bad territories. If you do create a new one, feel free to cc me on it.

When you say "no network connection active", what does it mean? While in that state, please run 'ip addr | UP' in a terminal and show us the output. (double-check that it doesn't contain any sensible data)

"online" in this regard means that there's at least one non-loopback network interface that's UP. It is perfectly possible that this definition of online doesn't match your view of whether you're online at the time.
Comment 99 Daniel Stenberg [:bagder] 2016-01-19 06:39:38 PST
Grr, I meant the command line to be "ip addr | grep UP", ie only showing the lines containing "UP"
Comment 100 nackd 2016-01-19 06:51:05 PST
You're right, if only loopback is up, it returns false.
Comment 101 Jose 2016-02-10 21:22:47 PST
Saludos, encontre esto: http://krawczyk.io/heyoffline.js/
Tengo este codigo:
<code>
<script type="text/javascript">
function updateCreativeCommons() {
document.getElementById('cc').innerHTML = navigator.onLine ? 
'<img alt="Licencia de Creative Commons" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" />' :
'<img alt="Licencia de Creative Commons" style="border-width:0" src="../media/imagen/88x31.png" />';
   }
  </script>
  <body>
   <a target="_blank" rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/es/">
<body onload="updateCreativeCommons()" ononline="updateCreativeCommons()" onoffline="updateCreativeCommons()">
<span id="cc"></span>
</a>
</body>
</code>
 y al intentar link cambia a status online a pesar de estar offline pueden ayudarme a implementar el nuevo codigo??
Comment 102 Andrew 2016-05-10 13:05:40 PDT
In the interest of updating documentation, it actually sounds like the behavior of this feature *is* consistent across Windows, OS X, and Linux.  

Correct?
Comment 103 Daniel Stenberg [:bagder] 2016-05-10 14:02:09 PDT
> it actually sounds like the behavior of this feature *is* consistent

I believe it is, yes.

Note You need to log in before you can comment on or make changes to this bug.