Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of simon.macdonald@gmail.com
 designates 209.85.210.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABiQX1V8yrsKG_BgdQbiPoLas7JXRPCtB-TbGVJCj9wVDY93hA@mail.gmail.com>
References: 
 <CABiQX1V8yrsKG_BgdQbiPoLas7JXRPCtB-TbGVJCj9wVDY93hA@mail.gmail.com>
From: Simon MacDonald <simon.macdonald@gmail.com>
Date: Fri, 31 Aug 2012 16:21:28 -0400
Message-ID: 
 <CAM1AYQBStcYM97Mss-j152qGjxN=A1bua5x4G-UaCL5FP3FR4w@mail.gmail.com>
Subject: Re: online events
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b339bf1adc0aa04c8958a45

--047d7b339bf1adc0aa04c8958a45
Content-Type: text/plain; charset=ISO-8859-1

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 <agrieve@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?
>

--047d7b339bf1adc0aa04c8958a45--