incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: online events
Date Fri, 31 Aug 2012 20:27:19 GMT
My vote is to keep what we currently document (document.addEventListener)
- for now.

We should be compiling an "API Review List" on the wiki or something and
taking notes of all these spec changes, and recommended implementation
routes for the project.

On 8/31/12 1:21 PM, "Simon MacDonald" <> wrote:

>Yeah, specs change. Here is the one we originally implemented:
>sharp eyes will note they are using navigator.connection.type and we are
>using That's because the Android web
>view would not allow us to over-ride navigator.connection. It seems to be
>read only object.
>Simon Mac Donald
>On Fri, Aug 31, 2012 at 3:49 PM, Andrew Grieve <> wrote:
>> It looks like there is code in network.js that fire online & offline
>> when the network status changes. On any platform that already supports
>> online events, the browser will fire an event, and then the network
>> will also fire an event.
>> There is also the fact that the event is fired only on document. The
>> says that listening on window should work as well (as well as
>> document.body):
>> I made a test page:
>> Running it on android browser shows that the only two listener methods
>> work are:
>>  -window.addEventListener
>>  -document.body.ononline =
>> So, clearly it's a bit broken. I'm wondering though, if we should do
>> clean-up with these events.
>> Options:
>> 1. Live with duplicate events for browsers that support them, but also
>> 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?

View raw message