Bug 11284 – navigator.onLine not implemented

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Dan Waylonis]

The onLine property of the navigator object returns undefined.  In Firefox, it returns true or false, depending on the reachability of the network.  I suggest using the SCNetworkCheckReachabilityXXX routines.

[Alexey Proskuryakov]

SCNetworkCheckReachabilityXXX routines take a target name/address - which one should we test against? For example, should navigator.onLine be true when the only active interface is loopback (e.g. testing with a locally installed Apache)?

Personally, I've always found the Netscape/Firefox "Offline mode" confusing, but maybe I'm missing some important use case?

(In reply to comment #1)
> SCNetworkCheckReachabilityXXX routines take a target name/address - which one
> should we test against?

I would assume that a script is most likely to be interested in whether the domain it's coming from is reachable, so I'd use that domain (when applicable).

[Dan Waylonis]

Created attachment 11121 [details]
Add support for navigator.{onLine,cpuClass}

This patch adds support for navigator.{onLine,cpuClass} properties.

[Alexey Proskuryakov]

(In reply to comment #2)
> I would assume that a script is most likely to be interested in whether the
> domain it's coming from is reachable, so I'd use that domain (when applicable).

As far as I understand what Firefox does, it is something different - just a flag indicating that the browser is in "offline mode" (and it's put in this mode manually).

[Erik Arvidsson]

Both IE and Firefox has a menu item to manually set the browser offline. The navigator.onLine reflect that state.

[William J. Edney]

I can confirm that this property is not implemented in Webkit (at least not on "AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13").

Can someone mark this as New?

Since it has been awhile since this bug has been poked, I'll add a bit of detail here. Feel free to comment if you find these statements inaccurate. More detail can be found here:

http://developer.mozilla.org/en/docs/Online/Offline_Events

To summarize, IE and Firefox implemented this property awhile back (IE has had it since 4.0!). It was originally meant to only indicate whether the user has chosen via a menu item or some other GUI element to 'go offline'.

In FF 2.0, this property is also set to true or false depending on whether the actual network connection is up or down. This capability is being brought to IE8, as detailed towards the bottom of this article:

http://msdn2.microsoft.com/en-us/library/cc304129(VS.85).aspx

Also, FF 3.0 and IE8 will be implementing the 'online' and 'offline' events (in IE8, you'll use 'ononline=' and 'onoffline=' and in FF you can use those or addEventListener()). These events are detailed in the two articles given above. Should we open a new bug asking that those events be implemented for Webkit too??

Either way, at a minimum 'navigator.onLine' should be fixed. Its been around for a while and is becoming more important with the advent of more Web stuff 'going offline'.

Comments or suggestions??

Cheers,

- Bill

[Alexey Proskuryakov]

In order to make any progress on this, we should find out what Firefox and IE 8 actually do. 

Mozilla documentation says: "Additionally, this property should update whenever a browser is no longer capable of connecting to the network." MS documentation says the same. Technically, this does not make much sense, as a browsers can always connect to some networks - at least, the loopback (127.0.0.1) one. This is not just a semantic game - consider a browser that is inside an intranet without any access to the wider Internet. A check such as one made in the attached patch (whether www.webkit.org is reachable) would not make any sense for it. Often, there are several active networks at once (e.g. loopback + intranet + a GPRS link to the outer word + a dummy network created by VMWare or Parallels). What's a browser to do?

As for onoffline/ononline events - are they supposed to fire when the user gets on or off VPN, for example? Some network destinations become reachable or not depending on VPN status, obviously, so this is something a Web application needs to be informed of, too.

[William J. Edney]

Alexey -

Thanks for the quick reply. I will volunteer to test FF 3.0 and IE 8b1 to let you know what they actually do, but here is my opinion:

Given my mindset as a 'strict client side' developer, I would tend to have a 'strict' interpretation of this property.

That is, if the network is inaccessible from script (i.e. posting a form or using XHR with 'http://' URLs or trying to set the '.src' attribute of an <img> tag dynamically, etc. etc.) and those operations are failing, I would consider the browser to be 'offline'.

Therefore, if the browser can 'talk to a web server', whether it is running on my localhost box, my local Intranet, a VPN, some weird thing like VMWare/Parallels shared networking, etc. etc. then I would consider the browser to be 'online'. Otherwise, it is 'offline'.

Therefore, like you, I find this patch to be woefully inadequate. To me, this is something that a chunk of C code that's talking to Webkit's networking layer needs to test (as in, 'gee I lost my network link').

I will have those test results for you later today.

Cheers,

- Bill

[William J. Edney]

Alexey -

So, as promised, I did some testing. Unfortunately, as per usual, there is no consistency.

I have a page that alert()s the value of navigator.onLine (note the spelling - its *exactly* that capitalization in both FF and IE). My environment is XP SP2.

Note here when I say 'the browser is in "online" or "offline" mode' what I mean by that is that the user has selected the Work Offline menu item (which is present in both FF and IE - but curiously missing in Safari... hmmm...)

Here are the results:

FF 2.0.0.12:

1. When the browser is in online mode and the network is active, the property is true. In my mind this is correct.

2. When the browser is in offline mode and the network is active, the property is false. In my mind this is correct.

3. When the browser is in online mode, but the network adaptor has been disabled by using the Windows Control Panel "Network Adaptors" panel, the property is still true. In my mind, this is incorrect and it tells me that the part of the referenced article on Firefox where they said that "Network status autodetection was implemented in Firefox 2" is not telling the truth (or maybe there's a bug ;-) ).

FF 3.0

1. When the browser is in online mode and the network is active, the property is true. In my mind this is correct.

2. When the browser is in offline mode and the network is active, the property is false. In my mind this is correct.

3. When the browser is in online mode, but the network adaptor has been disabled by using the Windows Control Panel "Network Adaptors" panel, the property is false (yay!). In my mind this is correct and tell me indeed that "Network status autodetection was implemented in Firefox *3*"

IE8beta1:

1. When the browser is in online mode and the network is active, the property is true. In my mind this is correct.

2. When the browser is in offline mode and the network is active, the property is false. In my mind this is correct.

3. When the browser is in online mode, but the network adaptor has been disabled by using the Windows Control Panel "Network Adaptors" panel, the property is still true. In my mind, this is incorrect and it tells me that there's a bug in IE8. I have, in fact, just reported this as a bug to the IE team, so we'll see if they agree.

IMHO, Safari should follow the FF 3.0 behavior above.

Let me know if there is further information or testing I can do for you.

Cheers,

- Bill

[Alexey Proskuryakov]

> 3. When the browser is in online mode, but the network adaptor <...>

My main concern is that there is no "the" network adaptor - there are many network adaptors. Which one should we look at? This is not a rare situation that can be ignored.

[William J. Edney]

Alexey -

My initial response would be 'all of them'.

More information on the IE8 situation - it looks as if the dynamic updating of the navigator.onLine property based on network connectivity situation and not just user preference and the 2 new events that get fired are only supported on Vista, which is why I wasn't seeing them. I've let the IE guys know what I think of that, but whether that does any good I don't know.

Cheers,

- Bill

[Alexey Proskuryakov]

<rdar://problem/5931742>

[Alexey Proskuryakov]

Some kind of support for this landed in <http://trac.webkit.org/projects/webkit/changeset/33457>.

[William J. Edney]

Folks -

It appears like this is broken on Webkit / Mac as of webkit build 37790. As the network interface is brought down and up, the navigator.onLine property doesn't change nor do the 'online' or 'offline' events fire. At one point, I'm almost certain that this worked, but it doesn't anymore.

Also, it doesn't appear like this functionality ever worked on Webkit / PC. I'm running build 37819 on that platform (on Windows XP) and none of this functionality works there either.

As per my earlier comment above, this functionality only worked for Vista in IE8b1, but at my behest the IE8 team fixed it so that these things do work on IE8b2 for XP.

Should we reopen this bug for both of these issues, or should we just reopen it for the Mac and I'll open a new bug for the PC?

Thanks!!

Cheers,

- Bill

[William J. Edney]

This functionality continues to be completely broken for Webkit v40663 on Mac
and Windows and Chrome up through 2.0.160.0.

The Mozilla guys have put up a new set of pages describing the functionality
here:

https://developer.mozilla.org/En/Online_and_offline_events

This has a link to a test page there that confirms the bustage.

Can we please reopen this bug?

Thanks!

Cheers,

- Bill

P.S. I have filed this bug with the Chromium team for that browser:

http://code.google.com/p/chromium/issues/detail?id=7469

[Alexey Proskuryakov]

> This functionality continues to be completely broken for Webkit v40663 on Mac
> and Windows and Chrome up through 2.0.160.0.

Chances are that it's working as specified (it certainly did for me last time I checked). Please see bug 32327 for some examples where the behavior gets confusing.