Yeah, specs change. Here is the one we originally implemented: http://www.w3.org/TR/netinfo-api/
sharp eyes will note they are using navigator.connection.type and we are using navigator.network.connection.type. That's because the Android web view would not allow us to over-ride navigator.connection. It seems to be a read only object. Simon Mac Donald http://hi.im/simonmacdonald On Fri, Aug 31, 2012 at 3:49 PM, Andrew Grieve <agri...@google.com> wrote: > It looks like there is code in network.js that fire online & offline events > when the network status changes. On any platform that already supports > online events, the browser will fire an event, and then the network plugin > will also fire an event. > > There is also the fact that the event is fired only on document. The spec > says that listening on window should work as well (as well as > document.body): http://www.whatwg.org/specs/web-apps/current-work/ > > I made a test page: > https://dl.dropbox.com/u/6648754/webtests/online_events.html > Running it on android browser shows that the only two listener methods that > work are: > -window.addEventListener > -document.body.ononline = > > So, clearly it's a bit broken. I'm wondering though, if we should do some > clean-up with these events. > > Options: > > 1. Live with duplicate events for browsers that support them, but also fire > them on document.body and window. > 2. Don't fire online/offline events from this plugin. Fire a custom > "networktypechange" event > 3. Intercept all event registration an window/document/body so that the > browser's native events don't take effect. Have the only source of these > events be the network plugin. > > > Votes? Comments? >
