Hacker News new | past | comments | ask | show | jobs | submit login
Heyoffline.js warns your users when their network becomes unreachable (oskarkrawczyk.github.com)
109 points by wassago on Nov 22, 2012 | hide | past | favorite | 34 comments



Today I learnt something that I didn't know exist, so i'm actually really glad that you linked this project, it made me look for details on the spec/standard.

First of all, I looked through your code and couldn't understand how this was implemented. After I found it and researched, it's clear that it's essentially useless[1].

I'm not bashing on your project, I like it, but aside from being a cool gimmick, I can't think of any real world usages?

...Unless your application is LAN-based , offline-heavy, or your have pixies that run around your office pulling out your network cable regularly * chuckles *.

I'll explain, but please correct me if I am way off the mark.

The project connects to the network events

     this.events = {       
        network: ['online', 'offline']
      };
These events fire from observing the attribute

    window.navigator.onLine
This attribute returns true, when the system is connected to a network, but returns false when it isn't.

The importance of this is that the attribute is inherently unreliable. A computer can be connected to a network without having Internet access. [2]

This is a barebones minimal example that doesn't have the features you added:

   <!DOCTYPE HTML>
    <html>
     <head>
      <title>Online status</title>
      <script>
       function updateIndicator() {
         document.getElementById('indicator').textContent =
                       navigator.onLine ? 'online' : 'offline';
       }
      </script>
     </head>
     <body onload="updateIndicator()" onoffline="updateIndicator()">
      <p>The network is: <span id="indicator">(state unknown)</span>
     </body>
    </html>
You can see the fiddle here: http://jsfiddle.net/3rRWK/

If you disconnect yourself from your network you will see the fiddle update to "Offline", however, if you pull your phone-line from your router, it will still stay at "Online".

    [1] : It's inherently unreliable. 
          A computer can be connected to a network without internet access.
    [2] : http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html


> A computer can be connected to a network without having Internet access.

In fact, as the Internet is essentially a network of networks some of which may be connected and disconnected at arbitrary points in time, it is a bit difficult to strictly define what it means to have Internet access.

In practice it would probably mean something like "can access a large majority of servers that consider themselves to be Internet servers", which is however impractical to test for. A "good enough" substitute is often enough to test connectivity to a few representative services which are unlikely to be unreachable all at the same time if you consider yourself to have "Internet access" (Google, Amazon, ...).

In this case it would however be best to test connectivity between the user and the specific server that the user is supposed to access.


Usually it's pretty irrelevant which servers are accessible except the ones that host your app/back-end. So that's what you should check when implementing such a feature.


An option would be to connect via websocket to a server and react on the disconnect event (doing some simple ping-pong to keep the connection alive). That would require an always-on websocket server though, which is a different story. Still could be good enough for a gimmick like this.


The always-on server could be provided as a (paying?) service, and there could be a polling fallback. That would be a lot more useful.


"it's clear that it's essentially useless"

Completely wrong. If 98% of the time (or even 50-97%)(i.e., reality) being connected to a network means also being connected to the internet, then it is useful. And it is also does not throw false negatives.


I took a quick look at the spec:

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

So, strictly speaking, if you have a network connection and no internet connectivity (and the browser is not aware of the latter), this should return true - because clicking a link will result in the browser contacting the network.

What would be really interesting to see is how this works with various browsers in Windows, because Windows does test connections for internet connectivity.


> ...Unless your application is LAN-based , offline-heavy, or your have pixies that run around your office pulling our your network cable regularly * chuckles *.

add in wireless device on a network that doesn't cover all areas of the building where the application is used.

We've had to handle this situation.


The issue with the OP's implementation and yours is that not all browsers implement navigator.onLine the same way. For example, if you run the jSFiddle on Firefox, you would see that the status does not change even if you pull out the cable or turn off WiFi. This is because of how Firefox chooses to interpret the spec. However, if you enable offline mode in Firefox (File -> Work Offline), you can see that the status changes.

This issue is described in greater detail here - http://schalk-neethling.com/2011/05/navigator-online-and-the...


I smell a feature addition that polls for some virtually-always-online internet resource, such as google.com, to routinely distinguish between the various values of 'online'.


Windows (and other OSes) already do this: http://blog.superuser.com/2011/05/16/windows-7-network-aware...

Basically, systems looks up a particular domain name and then requests a text file from that server. It then also checks if another domain name resolves to a hard-coded IP. If both checks pass, you're on the internet.


It may not be 100% reliable, but coupled with other techniques (catching error 404s etc) this provides a nice way to inform the user that their connection to our application may be gone.

For single page apps that use browser storage and sync to the remote periodically it is great to be able to inform the user that "Hey you're offline. You can keep using it, but your changes won't be available for others to see until you re-connect".


Wouldn't it be easier and more reliable to just catch the failed sync?


Aah, that explains why it didn't work for me (VM network cards were still active). Seems to me like setTimeout-based polling to your server or something like http://www.msftncsi.com/ncsi.txt is still the best option.


If you want to roll your own UI (something less obtrusive, perhaps), this can be done in only a few lines of code. From our Backbone.js app...

    (function() {
        var errorView = null;
        $(window).on('online', function() {
            if (errorView) errorView.close();
            errorView = null;
        });
        $(window).on('offline', function() {
            errorView = new ErrorView({ message: 'No internet connection.'});
            errorView.render();
        });
    }());


Looks good to me. We run an internal web app which relies on users being connected to a local server. This is perfect for my needs.


This looks great - but that sub-headline is almost unreadable (too thin/too light) "Warn your users when their network etc." (Chrome OSX)


I press the red button in the latest version of Firefox and nothing happens. The cursor doesn't change when I hover over the button.


It's not a button, you actually have to disconnect from the internet for the demo.


Considering that it's right next to it an identically rendered element that IS a button, it definitely appears to be a button itself. The example page should be changed to prompt the user to disconnect in another manner so that visitors don't get confused.


This should be a browser feature, extension or user script, not a website feature.


You might want a notification like this at the application level for the sake of consistency. For instance, Gmail's "Loading..." messages will also notify you when you have lost or gained a connection.

Surely consistent messaging and notifications is better for the user. Chrome has a desktop notifications API, but that's only appropriate for certain types of messages, such as receiving a new email. In general, it's probably best to handle messaging at the application level.


This is really cool. Thank you for sharing!


works in chrome, doesn't work in an admittedly old firefox or IE8


The FF window.navigator.onLine event fires when you click the "Work offline" option in the menu, at least I think it used to. Just tried that and it didn't work either.

I have been looking for a X-browser way to do this myself and the best I cam up with so far was to ping google.com with a XHR OPTIONS type request. Pretty ugly, but it works.


Would not a better solution be to ping a resource on the application server rather than an external resource (in this case Google)?

If the resource can't be pinged, it means either the user is offline or the app is down which are essentially the same thing for your app in most cases, while in your implementation, it could just mean Google.com is down (There is very low chance of this happening. Still..)

EDIT: Made the second paragraph clearer.


Hm, I clicked 'work offline' in firefox and didn't see the demo page do anything - maybe I'm missing something.


Yes, you're right. I know that that was the behaviour at some point in the past on OSX. But I tried just now on Windows, FF Nightly and saw nothing.

Could be a change in FF, difference in os's, or something in the library. Not a very helpful comment I'm afraid.


This library depends on the navigator.onLine spec. It does not work on Firefox as expected because it implements navigator.onLine differently from Chrome and IE. http://schalk-neethling.com/2011/05/navigator-online-and-the...


Same for me. Works perfectly in Chrome 23.0.1271.64 but not in Firefox 17.0, but tested on Ubuntu 12.04


Didn't work for me in Chrome 22.0.1229.94 on Windows

* Worked after I relaunched Chrome and updated to 23.0.1271.64


Very cool!


Why do these comments get downvoted? Granted that they add no value except to the author, that is still a valuable thing.


Its a cheap comment and may be misleading. If they can't explain why they like it, calling it cool is suspect.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: