onoffline and ononline events should fire when connection status changes




5 years ago
2 years ago


(Reporter: Brian Blakely, Assigned: bagder)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




5 years ago
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:


Expected results:

These events should fire appropriately


5 years ago
Component: Untriaged → DOM: Events
Product: Firefox → Core
QA Contact: untriaged → events
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.
Component: DOM: Events → Networking
QA Contact: events → networking
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

5 years ago
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.
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

5 years ago
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.
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

5 years ago
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.
> 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

5 years ago
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

5 years ago
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

5 years ago
Ah, there's also https://bugzilla.mozilla.org/show_bug.cgi?id=654579
Depends on: 783516

Comment 12

4 years ago
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.
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 12 Branch → Trunk
Blocks: 886487


3 years ago
Depends on: 939318


3 years ago
Duplicate of this bug: 987288
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...
Flags: needinfo?(jduell.mcbugs)
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).
Flags: needinfo?(jduell.mcbugs)
Needinfo-ing David with regards to the timeline in comment 15.
Flags: needinfo?(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.
Flags: needinfo?(dbialer)
The workaround is being discussed in bug 1020812, ftr

Comment 19

3 years ago
This is being work on in bug 1134596


3 years ago
Depends on: 1134596


2 years ago
Assignee: nobody → daniel

Comment 20

2 years ago
This is fixed since bug 1134596 landed
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.