756364 - onoffline and ononline events should fire when connection status changes

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Brian Blakely]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5

Steps to reproduce:

1. Ran this demo: http://jsfiddle.net/brianblakely/LxxhY/
2. Turned off my network adapter


Actual results:

Nothing


Expected results:

These events should fire appropriately

Comment 1

[Boris Zbarsky [:bzbarsky]]

I believe we fire the events when necko changes from online to offline mode or vice versa.

That _used_ to happen on things like turning off the network adapter: see bug 371667.

No idea whether it still does, though: there was something going on where autodetection of online mode was turned off at some point.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Ah, see comments in bug 654579.

As far as I can tell, our implementation is per spec, though the spec it not all that useful.

Comment 3

[Brian Blakely]

For what it's worth, WebKit fires these events when the user is no longer able (or again able) to retrieve online data from an app.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Determined how?  If the user has a network link to their wireless router but the wireless router loses internet connectivity, do they fire these events?

Comment 5

[Brian Blakely]

I have, at this moment, conducted a series of tests for you.

Scenarios that pass the test case in WebKit (Chrome & iOS Safari):

* Pulling out/Plugging in ethernet cable.
* Connecting to a new WiFi network.
* Moving into a WiFi dead zone and back.
* Going into the New York subway and back onto the street on an iPhone.
* Going into and out of Airplane Mode on an iPhone.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yes, sure.  Basically measuring local computer network state.  But the point is that just because you're connected to a wifi network doesn't mean that you can "retrieve online data from an app".

Furthermore, there are situations (esp. on Windows) in which the computer is not connected to a network but as soon as you try to touch the network it will connect to one.  So just returning "offline" when not connected to a network is wrong too.

Comment 7

[Brian Blakely]

Those test cases should work in Firefox to at least the same degree.  Right now, they don't fire at all, not even giving the developer a fuzzy (though it really isn't THAT fuzzy) view of the user's connection status.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Those test cases should work in Firefox to at least the same degree.

Doing that would break other cases, as I pointed out in comment 6.

Right now the behavior is pretty straightforward: if the browser goes into offline mode, we fire the offline event.  When it comes out of offline mode, we fire the online event.  The online state is an indication of browser mode, not the state of the network between the browser and you (which is not really known to the browser anyway).  So all you can depend on is that if the browser is offline it _definitely_ can't reach your server.

Comment 9

[Brian Blakely]

I've possibly grilled this feature in the past week more than most frontend developers who don't work at Google ever have, and the offline event never fired in WebKit when I was actually able to send and receive bits over the interwebs.

Right now, the behavior in Firefox is straightforward, but tied to a menu item that 99.99% of nobody uses, or ever has used.

Plz fix?  Pretty pretty plz?

Comment 10

[marcusjt]

I agree that (as per WebKit) network connectivity should be automatically & continually monitored, firing ononline/onoffline events whenever connectivity is lost/gained - i.e. not only when the user manually triggers a state change via the menu items.

This view is also held by notable JS developer Remy Sharp - see http://remysharp.com/2011/04/19/broken-offline-support/ (note that Chrome changed their mind so the article's criticism no longer applies to them AFAIK)

I also notice that there is an existing bug for this, which perhaps this one should be merged with - see https://bugzilla.mozilla.org/show_bug.cgi?id=620472

Comment 11

[marcusjt]

Ah, there's also https://bugzilla.mozilla.org/show_bug.cgi?id=654579

Comment 12

[Shuhao]

This behaviour is implemented in Firefox OS as well. Can't confirm for Fx for Android at the moment.

While navigator.onLine is not necessarily the best solution, the problem here is that it is inconsistent and unexpected.

Comment 14

[(no longer active)]

Jason, do you know what the status of this bug is, and whether this is something that we can expect to fix on Firefox OS in the near future?  The MarketPlace team asked me about whether we have an API that properly reflects the status of the network, and I think this is probably the right API (although comment 6 is thought-worthy) but I'm not sure whether we should be expecting a fix here...

Comment 15

[Jason Duell]

So after talking to the necko folks who are in this area, I think the story is that bug 939318 is coming first (which won't solve this bug but lays some infrastructure for it).  I'm taking the comments here (especially comment 5 and comment 14) as reason to bump this bug up in priority on our backlog.  But we're still looking at Q3 unless I hear reasons why it needs to be done sooner (and then I can't guarantee it--but feel free to ask if it merits it).

Comment 16

[(no longer active)]

Needinfo-ing David with regards to the timeline in comment 15.

Comment 17

[David Bialer [:dbialer]]

We currently have workarounds.  FxOS 2.0 would be nice though not urgent. I'm trying to figure out how a Q3 fix would align with Firefox OS release number? 

Bug 654579 is the issue.

Comment 18

[Wil Clouser [:clouserw]]

The workaround is being discussed in bug 1020812, ftr

Comment 19

[Daniel Stenberg [:bagder]]

This is being work on in bug 1134596

Comment 20

[Daniel Stenberg [:bagder]]

This is fixed since bug 1134596 landed