Closed Bug 654579 Opened 13 years ago Closed 9 years ago

navigator.onLine status for Offline Applications (navigator.onLine always returns true for desktop Firefox unless "work offline" is manually selected)

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed
relnote-firefox --- 41+

People

(Reporter: volume4.schalk, Assigned: valentin)

References

(Depends on 1 open bug)

Details

(Keywords: dev-doc-complete, relnote)

Attachments

(2 files, 1 obsolete file)

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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
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.
> 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.
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
Resolution: INVALID → WORKSFORME
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.
No idea about the menu thing.  That's Windows-specific; on Mac it's just under the File menu.
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.
Like I said, no idea.  That'd be a Firefox issue, not a core issue...
(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
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.
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.
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.
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
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.
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
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/
Status: RESOLVED → REOPENED
blocking-basecamp: --- → ?
Ever confirmed: true
Resolution: WORKSFORME → ---
(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.
That sounds like a good idea to me yeah.
Clearing nom and letting this bug just cover desktop.
blocking-basecamp: ? → ---
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.
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 :)
> 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.
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.
> 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.
> 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.
> 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.
@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".
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.
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.
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.
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.
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 :-/.
> 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
See Also: → 886487
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?
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.
(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.
Thanks for the pointer. I envy Chrome and Safari where the auto detection is enabled.
(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.
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 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.
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.
(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.
Summary: navigator.onLine status for Offline Applications → navigator.onLine status for Offline Applications (navigator.onLine always returns true for desktop Firefox unless "work offline" is manually selected)
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.
(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...
Assignee: nobody → daniel
(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.
(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).
(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.
(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?
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?
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.
Ah! Right! Good point. That resolves my concern.
(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.
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?
(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.
Depends on: 1139453
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.
(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...
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.
No longer blocks: 1157017
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.)
Blocks: 1157943
Flags: needinfo?(daniel)
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?
(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?
(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.
Assignee: daniel → valentin.gosu
Status: REOPENED → ASSIGNED
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?
Attachment #8620630 - Flags: review?(jduell.mcbugs) → review?(daniel)
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.
Flags: needinfo?(daniel)
Attachment #8620630 - Flags: review?(daniel) → review+
(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?
I'd like to see Bug 756364 solved as well.
(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?
See Also: → 1173931
(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
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?
https://hg.mozilla.org/mozilla-central/rev/fc9297fa66aa
Status: ASSIGNED → RESOLVED
Closed: 13 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
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
Flags: needinfo?(valentin.gosu)
(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.
Flags: needinfo?(valentin.gosu)
Thank you Valentin. I'll check it out in tomorrows build
Valentin- navigator.onLine still always returns true (testing in nightly v41.0.a1)
Only when I set the appropriate flag does it work correctly
Same here, the network.manage-offline-status pref is still false by default on the latest Nightly build at least for OS X.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Attachment #8620630 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/51168e14388c
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
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
This was added to Firefox 41.0a2 release notes.
Tested in 41.0a2. It's working now. Great job
Depends on: 1182025
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
@Derek Moore - See bug 1173931. It may be relevant.

https://bugzilla.mozilla.org/show_bug.cgi?id=1173931
Posting this using 43.0.4. I can confirm this is *NOT* fixed on Linux.
(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?
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.
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.
Grr, I meant the command line to be "ip addr | grep UP", ie only showing the lines containing "UP"
You're right, if only loopback is up, it returns false.
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??
In the interest of updating documentation, it actually sounds like the behavior of this feature *is* consistent across Windows, OS X, and Linux.  

Correct?
> it actually sounds like the behavior of this feature *is* consistent

I believe it is, yes.
On Firefox 57 and window 10, i found that the navigator.onLine still alway = true, except when we turn on "Offline Mode".
did this bug been fixed? or at this time, is there any other way to check online offline by real network status?
(In reply to lamanh.blog from comment #104)
> On Firefox 57 and window 10, i found that the navigator.onLine still alway =
> true, except when we turn on "Offline Mode".
> did this bug been fixed? or at this time, is there any other way to check
> online offline by real network status?

Do you have VMWare installed? Or any extra virtual network interfaces?
This can affect the browser's ability to detect when it's offline.
i'm not install any  virtual network. I have tested on some PC in my company and result is the same,too. 
And because the navigator.onLine still able return 'false' on google Chorm when i disconnect my network , I don't think this issue is made by another software.
On Firefox 59.b013, navigator.onLine only reflects the “Offline Mode” status, and is equal to `true` even if there is no network connectivity at all (Wi-Fi disabled and all). It has been reported to me that it worked correctly on FF 58.

The MDN states that this behavior was fixed for FF 41 (https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine), does that mean there was a regression on that?

Seen on Windows 10, no VM system installed.
I confirm that there seems to be a regression in Firefox 59. Up to Firefox 58 navigator.onLine returned false when there was no network connectivity OR you set the browser offline. Since Firefox 59 it only return false only if you manually set the browser offline.
I'm attaching a HTML document with JavaScript code to test the bug.
There is some thing strange here, today, March 20,2018 after update to 59.0.1, navigator.onLine is reflect to my  network status, not offline Mode any more.
It's sound good,But according to other reports, it's seem  not stability.

when will you get this feature to work properly?

See comment 10 and 12.

This bug has been closed for years. Please open new bugs if you have encountered a bug.

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

Attachment

General

Created:
Updated:
Size: