Closed Bug 426932 Opened 16 years ago Closed 16 years ago

navigator.onLine doesn't correctly update when network connectivity changes

Categories

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

PowerPC
macOS
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: aza, Assigned: dcamp)

References

Details

(Keywords: fixed1.9.1, Whiteboard: [RC2-])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

According to http://developer.mozilla.org/en/docs/Online_and_offline_events: 

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)...

It doesn't do so on OS X.

Reproducible: Always

Steps to Reproduce:
1. https://bugzilla.mozilla.org/attachment.cgi?id=220609
2. Turn off internet connectivity
Actual Results:  
Nothing happens

Expected Results:  
Should switch to offline.

http://developer.mozilla.org/en/docs/Online_and_offline_events
http://ejohn.org/blog/offline-events/
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
This is the bug I was talking about earlier today. I.e., that on OSX one doesn't  receive the offline/online events when you physically disconnect from the internet (say by turning off your wireless).
Ugh -- too late to take this for FF3, I fear, but we should get on it ASAP to get in a 3.0.1 IMO.  Offline story is...not quite as strong with this problem. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Dave can you take a look at this?  We'd take something for 3.0.1 or if we happen to do an RC2
Assignee: nobody → dcamp
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9-
Whiteboard: [RC2?]
I don't think we should block on this. This is really a feature request that would require new code to be written --- we've never had code to detect system network connectivity on Mac. Yes, it would be nice to have, but the user can still select "Work Offline" from the File menu.
Also I'd be uncomfortable taking an implementation at this late date. We'd run the risk of changing the browser offline state at the wrong time, if there was a bug in our code or a quirk in the way OSX reports network connectivity.
I'd argue that this is not a feature request, but is instead an honest-to-goodness bug. The whole netless/offline stack is one of the touted features of Firefox 3 (http://developer.mozilla.org/en/docs/Firefox_3_for_developers), and the bug effectively breaks the ability for web authors to make cross-platform applications that can seamlessly transition from offline to online.

The use case is that I'm working on an netless-enabled word processing app on an airplane. I get back to the office and connect to the network. If the web-app could detect the offline/online transition it would just sync up at that point. Without that ability, it won't. The "Work Offline" menu item doesn't factor into the case where the web-app needs to handle the connectivity dying. 
(In reply to comment #6)
> The use case is that I'm working on an netless-enabled word processing app on
> an airplane. I get back to the office and connect to the network. If the
> web-app could detect the offline/online transition it would just sync up at
> that point. Without that ability, it won't. The "Work Offline" menu item
> doesn't factor into the case where the web-app needs to handle the connectivity
> dying. 

No, that's nonsensical -- we're going to get that notification after the network has gone away, so the app is already stranded.  When the user selects "Work Offline", the app can take whatever actions it would take on receiving a "network lost" notification.
I was just looking at the OS X SystemConfiguration framework documentation re:
network reachability [1] and realized that online/offline mode may actually
need to be site-specific, rather than global across the whole browser session. 
For instance, it could be the case that the user has a wired connection to a
LAN and is accessing one site through that in tab A, and is accessing google
through a wireless internet connection in tab B; should the wireless connection
go down, tab B should switch to offline mode, but tab A should stay in online
mode.

Based on what I've seen of the WhatWG specification, this doesn't seem to
violate it in any way--just means that rather than the online/offline mode
being browser-wide, it should be per-tab and always auto-detected, I assume?

(I did some searching and noticed that this has basically been a known frailty
since at least 2001, with bug 87717... Until this notion of browser-based vs.
page-based online/offline state is resolved, though, it seems to me as though
any efforts to auto-detect online/offline state for the whole browser will
always end up frustrating some of our users.)

[1]
http://developer.apple.com/documentation/Networking/Reference/SysConfig/SCNetworkReachability/index.html
What Shaver said. When we find out we've lost connectivity, it's obviously too late to sync anything. And most of the time there is no way to find out about impending connectivity loss in advance --- not only are there no APIs, but it's simply impossible to predict that the user is going to enter a tunnel, or a router is going to go down, or prepaid Internet access is about to expire, or the user is going to yank the network cable, etc etc.

So, applications have to be prepared to run offline without prior warning, which generally means they need to be continuously synced.
It's a known issue that connectivity is really per-server. However, making that part of the API would add a lot of complexity that would actually be very hard for applications to handle, e.g. if they make use of resources across multiple servers. We need to focus on making the common case of all-or-nothing connectivity work well before we go in that direction.
Ah, Shaver's right about that. However, here's the kicker: Because online/offline doesn't get signaled to the browser, the browser doesn't correctly know when to look in the application cache to get the offline when offline.

Here's case in point.

(1) On the Mac, go to http://starkravingfinkle.org/projects/offline/todo.html
(2) Disconnect your internet.
(3) Reload the page. Note that the page doesn't load -- you get a net failure message.
(4) Go the the File menu and select "Work Offline"
(5) Reload the page. It works!

Grrr.

Atul was able to reproduce this on a XP VM (host being OS X)

I should note that when I reproduced this on an XP VM, it wasn't the case that Windows XP thought a network cable was unplugged; I actually disabled wireless on my host OS X system, which would've rendered the VMWare NAT disfunctional.  As a result, Windows XP probably didn't send any notifications that the network went down.
Here's a solution to the problem that shouldn't require any platform specific code:

(1) Attempt to connect to a page.
(2) At some point FF decides that the page cannot load and will display the "Can't Access Site" page.
(3) Before displaying that page, check to see if the site exists in the application cache (i.e., the thing that would appear if "Work Offline" had been selected).
(4) If it exists, show that instead of the "cannot access site" page. If it doesn't exist, show the "cannot access site" page.

This method solves the global/local problem that Atul talked about here: https://bugzilla.mozilla.org/show_bug.cgi?id=426932#c8, and hopefully won't require any largely new chunk of code. It should just work, and the user will never have to learn what this mysterious, non-visible, and non-obvious "Work Offline" thing is or how to use it.
R(In reply to comment #11)
> Ah, Shaver's right about that. However, here's the kicker: Because
> online/offline doesn't get signaled to the browser, the browser doesn't
> correctly know when to look in the application cache to get the offline when
> offline.

It does on Windows and Linux. As I said, there is a Mac-specific piece of work that needs to be done here.

> Atul was able to reproduce this on a XP VM (host being OS X)

(In reply to comment #12)
> I should note that when I reproduced this on an XP VM, it wasn't the case that
> Windows XP thought a network cable was unplugged; I actually disabled wireless
> on my host OS X system, which would've rendered the VMWare NAT disfunctional. 
> As a result, Windows XP probably didn't send any notifications that the
> network went down.

Right. There is no easy way to detect on-the-fly that, while the local network is up, some link between the local network and the Internet (or the site you care about) has gone down.

If you were using Windows on the base system and turned off wireless, or if you'd turned off networking in the VM, then that would have been detected by the browser and reported to the Web app.

An easy small fix that would help would be for network error pages to offer a "Work Offline" button or link so that users can easily and discoverably enter offline mode if they have to.

A bigger fix would be to support per-site offline mode and automatically enter it on network errors, but that needs considerable thought and careful design.
(In reply to comment #13)
> Here's a solution to the problem that shouldn't require any platform specific
> code:
> 
> (1) Attempt to connect to a page.
> (2) At some point FF decides that the page cannot load and will display the
> "Can't Access Site" page.
> (3) Before displaying that page, check to see if the site exists in the
> application cache (i.e., the thing that would appear if "Work Offline" had been
> selected).
> (4) If it exists, show that instead of the "cannot access site" page. If it
> doesn't exist, show the "cannot access site" page.
> 
> This method solves the global/local problem that Atul talked about here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=426932#c8, and hopefully won't
> require any largely new chunk of code. It should just work, and the user will
> never have to learn what this mysterious, non-visible, and non-obvious "Work
> Offline" thing is or how to use it.

This is probably a good idea but it's harder than it looks. Right now online/offline mode is a global thing so that would have to be changed. Then you have to deal with situations where you have a page some of whose resources are "online" and some "offline". That could get confusing for Web developers. You also have to figure out when and how to reenter the "online" state.
(In reply to comment #14)
> An easy small fix that would help would be for network error pages to offer a
> "Work Offline" button or link so that users can easily and discoverably enter
> offline mode if they have to.

I'm a fan of this approach for the near future.  Analogously, an actual button for "Switch to online mode" in the "Firefox is currently in offline mode and can't browse the Web"-style page--rather than the current static text saying "Place the browser in online mode and try again"--would be nice too.
> An easy small fix that would help would be for network error pages to offer a
> "Work Offline" button or link so that users can easily and discoverably enter
> offline mode if they have to.

That is at least better than what we have now, and is only a copy change. Especially if it is just a button they can click to try it out (as Atul says). If we go this route, we should as quickly as possible move to the bigger fix when time permits.

@Rob: How is it that you could have some resources online and offline at the same time?
(In reply to comment #16)
> (In reply to comment #14)
> > An easy small fix that would help would be for network error pages to offer a
> > "Work Offline" button or link so that users can easily and discoverably enter
> > offline mode if they have to.
> 
> I'm a fan of this approach for the near future.

Please file a new bug for that. You could probably fix it yourself, it's just a bit of chrome work.

> Analogously, an actual button
> for "Switch to online mode" in the "Firefox is currently in offline mode and
> can't browse the Web"-style page--rather than the current static text saying
> "Place the browser in online mode and try again"--would be nice too.

Yeah. Actually, we could make that even better; when we know for sure that there is no network available, we should not tell the user to put the browser in online mode and try again, since that isn't going to work. So we should have a different message for that case. Please file a new bug for that and feel free to take a crack at it...
Sure thing, I've just created bug 435323 and bug 435325.
Whiteboard: [RC2?] → [RC2-]
Folks -

I had mentioned this problem on bug 336359 comment 42 and have bugged both the Webkit and IE8 folks about this very issue on their platforms. I have not seen what I consider to be the correct behavior here in either Firefox 2.0 or 3.X on Mac or Windows (XP) or any Webkit build to date. I have seen it on IE8 beta 1, but only under Vista.

Firstly, this page is either incorrect, or is misleading:

http://developer.mozilla.org/en/docs/Online_and_offline_events

It makes the statement (under the section regarding 'navigator.onLine'):

"Firefox 2 updates this property when switching to/from the browser's Offline mode, and when losing/regaining network connectivity in Windows and Linux."

and later:

"Network status autodetection was implemented in Firefox 2."

How can that be when this bug is true for Firefox 3.0? Or is this describing different behavior such that I'm misreading this statement?

Second, the world I live in is a client-side state, AJAXified world. I expect that when the user loses network connectivity (i.e. either the network interface goes down or they choose 'Work Offline'), that the 'navigator.onLine' flag would dynamically change to false (without traversing a page - I don't do that in my world) and, in addition, now that we have these fancy online/offline events, that I'd get an offline event. Then I could prompt the user, via some DHTML-drawn GUI, and say 'hey, I just lost the network but I can save your data' and then do so to DOM storage, to the eventually-to-be-implemented SQL storage or heck even send it out as JSON-encoded data via a mailto: URL.

I realize this bug was filed for Mac OS X (probably in relation to the comment from the document above), but I'm not seeing the behavior I thought I'd see in any of these environments (FF3.0RC2 running on Windows XP or Mac - didn't try Linux). I see roc's comment 14 above, but I can't get it to work. And yes, I'm also running XP on a virtualized environment (Parallels) on the Mac and I actually disable Parallel's network interface such that XP believes it has lost its network connection. But 'navigator.onLine' just keeps reporting 'true'.

Anybody have any thoughts? Does this make any sense or am I way off base here? Can I help by writing testcases or something?

Cheers,

- Bill
(In reply to comment #20)
> Firstly, this page is either incorrect, or is misleading:
> 
> http://developer.mozilla.org/en/docs/Online_and_offline_events
> 
> It makes the statement (under the section regarding 'navigator.onLine'):
> 
> "Firefox 2 updates this property when switching to/from the browser's Offline
> mode, and when losing/regaining network connectivity in Windows and Linux."
> 
> and later:
> 
> "Network status autodetection was implemented in Firefox 2."
> 
> How can that be when this bug is true for Firefox 3.0? Or is this describing
> different behavior such that I'm misreading this statement?

Because this bug is specifically a Mac bug.

> Second, the world I live in is a client-side state, AJAXified world. I expect
> that when the user loses network connectivity (i.e. either the network
> interface goes down or they choose 'Work Offline'), that the
> 'navigator.onLine'
> flag would dynamically change to false (without traversing a page - I don't do
> that in my world) and, in addition, now that we have these fancy
> online/offline
> events, that I'd get an offline event. Then I could prompt the user, via some
> DHTML-drawn GUI, and say 'hey, I just lost the network but I can save your
> data' and then do so to DOM storage, to the eventually-to-be-implemented SQL
> storage or heck even send it out as JSON-encoded data via a mailto: URL.

That is how it should work.

> I realize this bug was filed for Mac OS X (probably in relation to the comment
> from the document above), but I'm not seeing the behavior I thought I'd see in
> any of these environments (FF3.0RC2 running on Windows XP or Mac - didn't try
> Linux). I see roc's comment 14 above, but I can't get it to work. And yes, I'm
> also running XP on a virtualized environment (Parallels) on the Mac and I
> actually disable Parallel's network interface such that XP believes it has
> lost its network connection. But 'navigator.onLine' just keeps reporting
> 'true'.

You should file a bug specifically on the Windows XP issue. It should be working. There may be an issue with the way Parallels configures the network interfaces.
I am running natively on Windows XP without virtualization and navigator.onLine never changes state and the new online and offline events are only sent when I use the "Work offline" menu item. Losing wireless signal or disabling my network adaptor have no effect with Firefox 3.0.
Please file a new bug about that!
Flags: blocking1.9.1?
Wouldn't stop 1.9.1 for this, but wanted, P2.  Feel free to argue. 
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2
Arguing :)

I've spoken to Dave Camp about this, and I think it's a pretty important thing for us to get right on OSX as well as Windows. I know that we're going to be doing more load from the offline cache in the 3.1 timeframe, but the events seem important for web apps.

(In reply to comment #22)
> I am running natively on Windows XP without virtualization and navigator.onLine
> never changes state and the new online and offline events are only sent when I
> use the "Work offline" menu item. Losing wireless signal or disabling my
> network adaptor have no effect with Firefox 3.0.

Hm, I just had kbrosnan confirm that on Windows things work as expected (events are fired) with Firefox 3.0.1 and 3.1, so I'm not sure what's happening in this comment.
Flags: blocking1.9.1- → blocking1.9.1?
Folks -

I'm the commenter for #20 above and I can confirm that Firefox 3.0.1 on Windows XP (emulated in VMWare Fusion for Mac) is properly signaling online/offline events and properly updating the navigator.onLine property, both when toggling the Work Offline menu item and when the networking interface is brought up and taken down

However, Firefox 3.0.1 on Ubuntu Linux 8.04 Hardy Heron (emulated in Parallels for Mac) only signals the offline/online events and updates the navigator.onLine property when toggling the Work Offline menu item, not when bringing the network interface up and down :-(.

Firefox 3.0.1 on Mac exhibits this same behavior :-(.

As a developer of 'web apps' (i.e. heavy AJAX where I keep a lot of state in JS in the browser and I'd like to know when the network itself actually goes down), I would love to get these platforms operating properly like their Windows counterpart. So, I'm going to second Mike's opinion that we need to get this sorted out and working for these other platforms... please! :-).

As I've done with other bugs, I'm offering a nice bottle of wine or case of beer for the person responsible for getting this bug to the FIXEd state :-)

Cheers,

- Bill
Ok, so now I'll add some more fuel to the fire :-).

I complained to the Microsoft folks about the fact that, on IE8 beta 1, the onLine property updating and the events firing as the network connectivity changed only worked on Vista. I wanted it to work for XP as well.

I just found out yesterday that they fixed that behavior for IE8 beta 2 such that those events and state changes now happen on XP as well.

C'mon folks!! Please fix this for Linux and Mac! Now there's browser pride at stake!! :-).

Cheers,

- Bill

P.S. My bottle of wine or case of fine beer offer from above still stands! :-)
We have had problems on Linux, for which the bug number eludes me, which boil down to "there is no reliable way to find out if the network is available or not".  So you might end up needing to send beverages to folks on that side of the stack, or more likely the distributors making the decisions about what versions of NetworkManager to ship, and how authoritative NM's claims about network state should be. :-/
(In reply to comment #28)
> We have had problems on Linux, for which the bug number eludes me, 

probably bug 424626 (dup ?)
@Mike - Thanks for the reply. It was what I'd feared - no reliable way to get that across distros (at least using NetworkManager).

@Antonio - Yes, that is the correct bug number.

Sigh...

Ok, so that leaves us with Mac. Anyone? :-)

Cheers,

- Bill
Flags: blocking1.9.1? → blocking1.9.1+
Attached patch WIP 1Splinter Review
This should work, but I need to verify that using 0.0.0.0 as the reachability address works on 10.4, and need to figure out if I'm getting the runloop the right way.
Can some explain why this is a blocker for 1.9.1? Re-nominating to make sure this is tracked and we all agree here.
Flags: blocking1.9.1+ → blocking1.9.1?
Besides comment #25, this bug puts a big hole in our offline event support. We have this support on Windows. We removed unreliable support on Linux because we can't depend on NetworkManager to help. If we can get reliable support for offline events on Mac, it would certainly help our offline webapp feature set.
Attached patch v1 (obsolete) — Splinter Review
Attachment #340419 - Flags: review?
Dave, who did you intend to review that?
Attachment #340419 - Flags: superreview?(roc)
Attachment #340419 - Flags: review?(smichaud)
Attachment #340419 - Flags: review?
Comment on attachment 340419 [details] [diff] [review]
v1

+    CFRetain(mCFRunLoop);

Generally we prefix C calls into Apple's frameworks with "::", so "::CFRetain(mCFRunLoop)".
Comment on attachment 340419 [details] [diff] [review]
v1

+    PRBool mLinkUp;
+    PRBool mStatusKnown;

PRPackedBool

+    // The network reachability API can reach 0.0.0.0 without
+    // requiring a connection, there is a network interface available.

Should there be an "if" in that comment?

Boy it'd be great to have some kind of nsCFPtr<>! But not in this bug.

+        reinterpret_cast<nsNetworkLinkService*>(info);

This can be a static_cast

Do we actually need to retain our own reference to mCFRunLoop? Seems like the mReachability object should be doing that itself.
I'm going to test this patch (on OS X 10.4.11 and 10.5.4).  But here's an
initial question (the code is from nsNetworkLinkService::SendEvent()):

+    if (mStatusKnown)
+        event = NS_NETWORK_LINK_DATA_UNKNOWN;
+    else
+        event = mLinkUp ? NS_NETWORK_LINK_DATA_UP
+                        : NS_NETWORK_LINK_DATA_DOWN;

Shouldn't the first line be "if (!mStatusKnown)"?
(In reply to comment #37)
> Do we actually need to retain our own reference to mCFRunLoop? Seems like the
> mReachability object should be doing that itself.

We need to hold on to its value for UnscheduleRunLoop, but I suppose we don't need to actually retain it.
(In reply to comment #39)

In my testing (using CFGetRetainCount()) I've found that
SCNetworkReachabilityScheduleWithRunLoop() does retain its "runLoop"
object (in fact more than once).  But it's not documented to do so (in
SCNetworkReachability.h).

So it may be best to continue retaining (and later releasing)
mCFRunLoop.
I'm about to post a v2 patch that incorporates most of the suggested changes, plus a couple of others (one of which was needed to make it compile).

I tested it on OS X 10.4.11 and 10.5.5 and had no problems.
Attached patch v2 patchSplinter Review
As I promised, here's a version of dcamp's patch that incorporates most of the
suggested changes, plus a couple more.

I tested this on OS X 10.4.11 and 10.5.5, using added NSLog statements to
observe when (for example) nsNetworkLinkService::UpdateReachability() and
nsNetworkLinkService::SendEvent() got called (and what they did once called).

I tested on a machine with an Ethernet connection.  So my tests consisted of
disconnecting and reconnecting the ethernet cable.  They worked as expected --
a few seconds after disconnecting or reconnecting the cable, I saw the
expected messages.  More complicated tests (say of wireless and dialup
connections) are also needed -- but I can't do them myself.

(By the way, I found that tne nsNetworkLink service is initialized before the
AppShell service.  But (as I expected) that doesn't seem to cause any
trouble.)
Attachment #340419 - Attachment is obsolete: true
Attachment #340637 - Flags: superreview?(roc)
Attachment #340637 - Flags: review?(joshmoz)
Attachment #340419 - Flags: superreview?(roc)
Attachment #340419 - Flags: review?(smichaud)
Dcamp:  As far as I'm concerned, I've r+ed your patch (including the changes I
made) :-)
I also tested starting up Minefield (and sometimes the machine itself) with
the Ethernet cable disconnected.  I got the expected results -- when called
from nsNetworkLinkService::Init(), nsNetworkLinkService::UpdateReachability()
set mLinkUp to PR_FALSE (reachable and needsConnection were both PR_TRUE).

Reconnecting the cable caused nsNetworkLinkService::UpdateReachability() (when
called again, on the "reachability change") to set mLinkUp to PR_TRUE
(reachable was PR_TRUE and needsConnection was PR_FALSE).

(Oops, just noticed that I forgot to turn mLinkUp and mStatusKnow into
PRPackedBool flags.)
Attachment #340637 - Flags: superreview?(roc) → superreview+
Attachment #340637 - Flags: review?(joshmoz) → review+
Changed to PRPackedBool and landed as http://hg.mozilla.org/mozilla-central/rev/3ea2c46a9814

Please open specific bugs for problems with online/offline state on the various platforms.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre. I verified using https://bugzilla.mozilla.org/attachment.cgi?id=220609 with both wireless and ethernet connections here in the office.
Status: RESOLVED → VERIFIED
Is this a dupe of bug 336285, in which case I'm super happy?
David -

I'm super happy too! I think this is a dupe of that bug, but someone else here with more knowledge than I of the issues should verify that and mark as DUP if that's the case.

Dave Camp, you have my sincerest thanks. As per comment #27, please contact me should you wish to collect :-).

Thank you again Dave!

Cheers,

- Bill
Depends on: 463046
Glad 1.9.1 gets the fix, but not an appropriate change for 3.0.x security updates.
Flags: wanted1.9.0.x+ → wanted1.9.0.x-
This landed prior to 1.9.1 branching
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
In Firefox 7.0.1 on Mac OS 10.6.8 (at least) navigator.onLine returns false if File > Work Offline is selected -- but doesn't respond to turning off Airport (i.e. still returns true).
(In reply to comment #52)

This sounds like a different bug -- possibly an Apple bug.

Please test with FF 8.0.1 (the current version) and today's mozilla-central (trunk) nightly (ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/).  If the problem persists, open a new bug on it.  When you do, please provide detailed information, including precise steps-to-reproduce.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: