You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2012/09/01 17:26:17 UTC
Re: online events
Figured out a work-around for clobbering things on navigator on Android
(tested on 2.1 and 2.3):
var newNavigator = {};
newNavigator.__proto__ = navigator;
newNavigator.__defineGetter__('onLine', function() {
return network.type != 'none';
});
newNavigator.connection = {type: 'wifi'};
window.navigator = newNavigator;
I'll hook this up so that connection and onLine will work properly (woohoo!)
As for events, I don't think document.body is common, but I think
window.addEventListener is quite common since it works on both mobile
safari and android browser. I'll add this to the API review list on the
wiki, but I do need to do something here in the short term since I need to
listen to the browser-fired window online/offline events to implement the
ONLINE_EVENTS exec bridge. How about just put in an android
only work-around for now:
cordova.addWindowEventHandler('online');
cordova.addWindowEventHandler('offline');
function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
document.addEventListener('online', proxyEvent, false);
document.addEventListener('offline', proxyEvent, false);
On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
> 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" <si...@gmail.com> wrote:
>
> >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 <ag...@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?
> >>
>
>
Re: online events
Posted by Andrew Grieve <ag...@chromium.org>.
Changes made and tested on Android + iOS. Will wait for 2.1.0 before
merging.
https://github.com/agrieve/incubator-cordova-js/commits/navigatorconn
On Tue, Sep 4, 2012 at 3:05 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Definitely. Will add this detail to the bug so it's explicit.
>
>
> On Tue, Sep 4, 2012 at 2:03 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> +1
>>
>> ya.
>>
>> On Tue, Sep 4, 2012 at 10:53 AM, Filip Maj <fi...@adobe.com> wrote:
>> > Sorry replied to the wrong thread.
>> >
>> > Can we make sure to keep the old navigator.network.connection API and
>> > introduce the new one?
>> >
>> > ALSO: add a deprecation message to any functions tacked on to the
>> > `connection` object?
>> >
>> > On 9/4/12 8:51 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >
>> >>Right...can't believe we didn't try duck punching all of navigator
>> before.
>> >>I remember everyone collectively trying to hack this. Anyhow: awesome.
>> Thx
>> >>Andrew!
>> >>
>> >>On Tuesday, September 4, 2012, Andrew Grieve wrote:
>> >>
>> >>> __proto__ just sets the prototype of an object. It's non-standard and
>> IE
>> >>> doesn't support it, but the following is equivalent:
>> >>>
>> >>> function ClassWithNavigatorAsPrototype() {}
>> >>> ClassWithNavigatorAsPrototype.prototype = navigator;
>> >>> var newNavigator = new ClassWithNavigatorAsPrototype();
>> >>>
>> >>> The idea is that we're not trying to overwrite onLine or connection.
>> >>>We're
>> >>> overwriting window.navigator with an object that has the old navigator
>> >>>in
>> >>> it's prototype chain.
>> >>>
>> >>> I'll make a bug to put this into bootstrap.js post 2.1.
>> >>>
>> >>>
>> >>> On Mon, Sep 3, 2012 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>> >>>
>> >>> > waaaaaat! how is this working?
>> >>> >
>> >>> > does the __proto__ allow to hack around writable data descriptor?
>> >>> >
>> >>> > (awesome stuff andrew)
>> >>> >
>> >>> >
>> >>> > On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <agrieve@chromium.org
>> >
>> >>> > wrote:
>> >>> > > Figured out a work-around for clobbering things on navigator on
>> >>>Android
>> >>> > > (tested on 2.1 and 2.3):
>> >>> > >
>> >>> > > var newNavigator = {};
>> >>> > > newNavigator.__proto__ = navigator;
>> >>> > > newNavigator.__defineGetter__('onLine', function() {
>> >>> > > return network.type != 'none';
>> >>> > > });
>> >>> > > newNavigator.connection = {type: 'wifi'};
>> >>> > > window.navigator = newNavigator;
>> >>> > >
>> >>> > > I'll hook this up so that connection and onLine will work properly
>> >>> > (woohoo!)
>> >>> > >
>> >>> > > As for events, I don't think document.body is common, but I think
>> >>> > > window.addEventListener is quite common since it works on both
>> >>>mobile
>> >>> > > safari and android browser. I'll add this to the API review list
>> on
>> >>>the
>> >>> > > wiki, but I do need to do something here in the short term since I
>> >>>need
>> >>> > to
>> >>> > > listen to the browser-fired window online/offline events to
>> >>>implement
>> >>> the
>> >>> > > ONLINE_EVENTS exec bridge. How about just put in an android
>> >>> > > only work-around for now:
>> >>> > >
>> >>> > > cordova.addWindowEventHandler('online');
>> >>> > > cordova.addWindowEventHandler('offline');
>> >>> > > function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
>> >>> > > document.addEventListener('online', proxyEvent, false);
>> >>> > > document.addEventListener('offline', proxyEvent, false);
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > > On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
>> >>> > >
>> >>> > >> 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" <simon.macdonald@gmail.com
>> >
>> >>> > wrote:
>> >>> > >>
>> >>> > >> >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
>> >>><ag...@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
>> >
>> >
>>
>
>
Re: online events
Posted by Andrew Grieve <ag...@chromium.org>.
Definitely. Will add this detail to the bug so it's explicit.
On Tue, Sep 4, 2012 at 2:03 PM, Brian LeRoux <b...@brian.io> wrote:
> +1
>
> ya.
>
> On Tue, Sep 4, 2012 at 10:53 AM, Filip Maj <fi...@adobe.com> wrote:
> > Sorry replied to the wrong thread.
> >
> > Can we make sure to keep the old navigator.network.connection API and
> > introduce the new one?
> >
> > ALSO: add a deprecation message to any functions tacked on to the
> > `connection` object?
> >
> > On 9/4/12 8:51 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >
> >>Right...can't believe we didn't try duck punching all of navigator
> before.
> >>I remember everyone collectively trying to hack this. Anyhow: awesome.
> Thx
> >>Andrew!
> >>
> >>On Tuesday, September 4, 2012, Andrew Grieve wrote:
> >>
> >>> __proto__ just sets the prototype of an object. It's non-standard and
> IE
> >>> doesn't support it, but the following is equivalent:
> >>>
> >>> function ClassWithNavigatorAsPrototype() {}
> >>> ClassWithNavigatorAsPrototype.prototype = navigator;
> >>> var newNavigator = new ClassWithNavigatorAsPrototype();
> >>>
> >>> The idea is that we're not trying to overwrite onLine or connection.
> >>>We're
> >>> overwriting window.navigator with an object that has the old navigator
> >>>in
> >>> it's prototype chain.
> >>>
> >>> I'll make a bug to put this into bootstrap.js post 2.1.
> >>>
> >>>
> >>> On Mon, Sep 3, 2012 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
> >>>
> >>> > waaaaaat! how is this working?
> >>> >
> >>> > does the __proto__ allow to hack around writable data descriptor?
> >>> >
> >>> > (awesome stuff andrew)
> >>> >
> >>> >
> >>> > On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <ag...@chromium.org>
> >>> > wrote:
> >>> > > Figured out a work-around for clobbering things on navigator on
> >>>Android
> >>> > > (tested on 2.1 and 2.3):
> >>> > >
> >>> > > var newNavigator = {};
> >>> > > newNavigator.__proto__ = navigator;
> >>> > > newNavigator.__defineGetter__('onLine', function() {
> >>> > > return network.type != 'none';
> >>> > > });
> >>> > > newNavigator.connection = {type: 'wifi'};
> >>> > > window.navigator = newNavigator;
> >>> > >
> >>> > > I'll hook this up so that connection and onLine will work properly
> >>> > (woohoo!)
> >>> > >
> >>> > > As for events, I don't think document.body is common, but I think
> >>> > > window.addEventListener is quite common since it works on both
> >>>mobile
> >>> > > safari and android browser. I'll add this to the API review list on
> >>>the
> >>> > > wiki, but I do need to do something here in the short term since I
> >>>need
> >>> > to
> >>> > > listen to the browser-fired window online/offline events to
> >>>implement
> >>> the
> >>> > > ONLINE_EVENTS exec bridge. How about just put in an android
> >>> > > only work-around for now:
> >>> > >
> >>> > > cordova.addWindowEventHandler('online');
> >>> > > cordova.addWindowEventHandler('offline');
> >>> > > function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
> >>> > > document.addEventListener('online', proxyEvent, false);
> >>> > > document.addEventListener('offline', proxyEvent, false);
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
> >>> > >
> >>> > >> 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" <si...@gmail.com>
> >>> > wrote:
> >>> > >>
> >>> > >> >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
> >>><ag...@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>
> >
>
Re: online events
Posted by Brian LeRoux <b...@brian.io>.
+1
ya.
On Tue, Sep 4, 2012 at 10:53 AM, Filip Maj <fi...@adobe.com> wrote:
> Sorry replied to the wrong thread.
>
> Can we make sure to keep the old navigator.network.connection API and
> introduce the new one?
>
> ALSO: add a deprecation message to any functions tacked on to the
> `connection` object?
>
> On 9/4/12 8:51 AM, "Brian LeRoux" <b...@brian.io> wrote:
>
>>Right...can't believe we didn't try duck punching all of navigator before.
>>I remember everyone collectively trying to hack this. Anyhow: awesome. Thx
>>Andrew!
>>
>>On Tuesday, September 4, 2012, Andrew Grieve wrote:
>>
>>> __proto__ just sets the prototype of an object. It's non-standard and IE
>>> doesn't support it, but the following is equivalent:
>>>
>>> function ClassWithNavigatorAsPrototype() {}
>>> ClassWithNavigatorAsPrototype.prototype = navigator;
>>> var newNavigator = new ClassWithNavigatorAsPrototype();
>>>
>>> The idea is that we're not trying to overwrite onLine or connection.
>>>We're
>>> overwriting window.navigator with an object that has the old navigator
>>>in
>>> it's prototype chain.
>>>
>>> I'll make a bug to put this into bootstrap.js post 2.1.
>>>
>>>
>>> On Mon, Sep 3, 2012 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>> > waaaaaat! how is this working?
>>> >
>>> > does the __proto__ allow to hack around writable data descriptor?
>>> >
>>> > (awesome stuff andrew)
>>> >
>>> >
>>> > On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <ag...@chromium.org>
>>> > wrote:
>>> > > Figured out a work-around for clobbering things on navigator on
>>>Android
>>> > > (tested on 2.1 and 2.3):
>>> > >
>>> > > var newNavigator = {};
>>> > > newNavigator.__proto__ = navigator;
>>> > > newNavigator.__defineGetter__('onLine', function() {
>>> > > return network.type != 'none';
>>> > > });
>>> > > newNavigator.connection = {type: 'wifi'};
>>> > > window.navigator = newNavigator;
>>> > >
>>> > > I'll hook this up so that connection and onLine will work properly
>>> > (woohoo!)
>>> > >
>>> > > As for events, I don't think document.body is common, but I think
>>> > > window.addEventListener is quite common since it works on both
>>>mobile
>>> > > safari and android browser. I'll add this to the API review list on
>>>the
>>> > > wiki, but I do need to do something here in the short term since I
>>>need
>>> > to
>>> > > listen to the browser-fired window online/offline events to
>>>implement
>>> the
>>> > > ONLINE_EVENTS exec bridge. How about just put in an android
>>> > > only work-around for now:
>>> > >
>>> > > cordova.addWindowEventHandler('online');
>>> > > cordova.addWindowEventHandler('offline');
>>> > > function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
>>> > > document.addEventListener('online', proxyEvent, false);
>>> > > document.addEventListener('offline', proxyEvent, false);
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
>>> > >
>>> > >> 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" <si...@gmail.com>
>>> > wrote:
>>> > >>
>>> > >> >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
>>><ag...@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>
>
Re: online events
Posted by Filip Maj <fi...@adobe.com>.
Sorry replied to the wrong thread.
Can we make sure to keep the old navigator.network.connection API and
introduce the new one?
ALSO: add a deprecation message to any functions tacked on to the
`connection` object?
On 9/4/12 8:51 AM, "Brian LeRoux" <b...@brian.io> wrote:
>Right...can't believe we didn't try duck punching all of navigator before.
>I remember everyone collectively trying to hack this. Anyhow: awesome. Thx
>Andrew!
>
>On Tuesday, September 4, 2012, Andrew Grieve wrote:
>
>> __proto__ just sets the prototype of an object. It's non-standard and IE
>> doesn't support it, but the following is equivalent:
>>
>> function ClassWithNavigatorAsPrototype() {}
>> ClassWithNavigatorAsPrototype.prototype = navigator;
>> var newNavigator = new ClassWithNavigatorAsPrototype();
>>
>> The idea is that we're not trying to overwrite onLine or connection.
>>We're
>> overwriting window.navigator with an object that has the old navigator
>>in
>> it's prototype chain.
>>
>> I'll make a bug to put this into bootstrap.js post 2.1.
>>
>>
>> On Mon, Sep 3, 2012 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > waaaaaat! how is this working?
>> >
>> > does the __proto__ allow to hack around writable data descriptor?
>> >
>> > (awesome stuff andrew)
>> >
>> >
>> > On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> > > Figured out a work-around for clobbering things on navigator on
>>Android
>> > > (tested on 2.1 and 2.3):
>> > >
>> > > var newNavigator = {};
>> > > newNavigator.__proto__ = navigator;
>> > > newNavigator.__defineGetter__('onLine', function() {
>> > > return network.type != 'none';
>> > > });
>> > > newNavigator.connection = {type: 'wifi'};
>> > > window.navigator = newNavigator;
>> > >
>> > > I'll hook this up so that connection and onLine will work properly
>> > (woohoo!)
>> > >
>> > > As for events, I don't think document.body is common, but I think
>> > > window.addEventListener is quite common since it works on both
>>mobile
>> > > safari and android browser. I'll add this to the API review list on
>>the
>> > > wiki, but I do need to do something here in the short term since I
>>need
>> > to
>> > > listen to the browser-fired window online/offline events to
>>implement
>> the
>> > > ONLINE_EVENTS exec bridge. How about just put in an android
>> > > only work-around for now:
>> > >
>> > > cordova.addWindowEventHandler('online');
>> > > cordova.addWindowEventHandler('offline');
>> > > function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
>> > > document.addEventListener('online', proxyEvent, false);
>> > > document.addEventListener('offline', proxyEvent, false);
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
>> > >
>> > >> 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" <si...@gmail.com>
>> > wrote:
>> > >>
>> > >> >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
>><ag...@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>
Re: online events
Posted by Brian LeRoux <b...@brian.io>.
Right...can't believe we didn't try duck punching all of navigator before.
I remember everyone collectively trying to hack this. Anyhow: awesome. Thx
Andrew!
On Tuesday, September 4, 2012, Andrew Grieve wrote:
> __proto__ just sets the prototype of an object. It's non-standard and IE
> doesn't support it, but the following is equivalent:
>
> function ClassWithNavigatorAsPrototype() {}
> ClassWithNavigatorAsPrototype.prototype = navigator;
> var newNavigator = new ClassWithNavigatorAsPrototype();
>
> The idea is that we're not trying to overwrite onLine or connection. We're
> overwriting window.navigator with an object that has the old navigator in
> it's prototype chain.
>
> I'll make a bug to put this into bootstrap.js post 2.1.
>
>
> On Mon, Sep 3, 2012 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > waaaaaat! how is this working?
> >
> > does the __proto__ allow to hack around writable data descriptor?
> >
> > (awesome stuff andrew)
> >
> >
> > On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > Figured out a work-around for clobbering things on navigator on Android
> > > (tested on 2.1 and 2.3):
> > >
> > > var newNavigator = {};
> > > newNavigator.__proto__ = navigator;
> > > newNavigator.__defineGetter__('onLine', function() {
> > > return network.type != 'none';
> > > });
> > > newNavigator.connection = {type: 'wifi'};
> > > window.navigator = newNavigator;
> > >
> > > I'll hook this up so that connection and onLine will work properly
> > (woohoo!)
> > >
> > > As for events, I don't think document.body is common, but I think
> > > window.addEventListener is quite common since it works on both mobile
> > > safari and android browser. I'll add this to the API review list on the
> > > wiki, but I do need to do something here in the short term since I need
> > to
> > > listen to the browser-fired window online/offline events to implement
> the
> > > ONLINE_EVENTS exec bridge. How about just put in an android
> > > only work-around for now:
> > >
> > > cordova.addWindowEventHandler('online');
> > > cordova.addWindowEventHandler('offline');
> > > function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
> > > document.addEventListener('online', proxyEvent, false);
> > > document.addEventListener('offline', proxyEvent, false);
> > >
> > >
> > >
> > >
> > > On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > >> 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" <si...@gmail.com>
> > wrote:
> > >>
> > >> >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 <ag...@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>
Re: online events
Posted by Andrew Grieve <ag...@chromium.org>.
__proto__ just sets the prototype of an object. It's non-standard and IE
doesn't support it, but the following is equivalent:
function ClassWithNavigatorAsPrototype() {}
ClassWithNavigatorAsPrototype.prototype = navigator;
var newNavigator = new ClassWithNavigatorAsPrototype();
The idea is that we're not trying to overwrite onLine or connection. We're
overwriting window.navigator with an object that has the old navigator in
it's prototype chain.
I'll make a bug to put this into bootstrap.js post 2.1.
On Mon, Sep 3, 2012 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
> waaaaaat! how is this working?
>
> does the __proto__ allow to hack around writable data descriptor?
>
> (awesome stuff andrew)
>
>
> On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > Figured out a work-around for clobbering things on navigator on Android
> > (tested on 2.1 and 2.3):
> >
> > var newNavigator = {};
> > newNavigator.__proto__ = navigator;
> > newNavigator.__defineGetter__('onLine', function() {
> > return network.type != 'none';
> > });
> > newNavigator.connection = {type: 'wifi'};
> > window.navigator = newNavigator;
> >
> > I'll hook this up so that connection and onLine will work properly
> (woohoo!)
> >
> > As for events, I don't think document.body is common, but I think
> > window.addEventListener is quite common since it works on both mobile
> > safari and android browser. I'll add this to the API review list on the
> > wiki, but I do need to do something here in the short term since I need
> to
> > listen to the browser-fired window online/offline events to implement the
> > ONLINE_EVENTS exec bridge. How about just put in an android
> > only work-around for now:
> >
> > cordova.addWindowEventHandler('online');
> > cordova.addWindowEventHandler('offline');
> > function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
> > document.addEventListener('online', proxyEvent, false);
> > document.addEventListener('offline', proxyEvent, false);
> >
> >
> >
> >
> > On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> 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" <si...@gmail.com>
> wrote:
> >>
> >> >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 <ag...@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?
> >> >>
> >>
> >>
>
Re: online events
Posted by Brian LeRoux <b...@brian.io>.
waaaaaat! how is this working?
does the __proto__ allow to hack around writable data descriptor?
(awesome stuff andrew)
On Sat, Sep 1, 2012 at 8:26 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Figured out a work-around for clobbering things on navigator on Android
> (tested on 2.1 and 2.3):
>
> var newNavigator = {};
> newNavigator.__proto__ = navigator;
> newNavigator.__defineGetter__('onLine', function() {
> return network.type != 'none';
> });
> newNavigator.connection = {type: 'wifi'};
> window.navigator = newNavigator;
>
> I'll hook this up so that connection and onLine will work properly (woohoo!)
>
> As for events, I don't think document.body is common, but I think
> window.addEventListener is quite common since it works on both mobile
> safari and android browser. I'll add this to the API review list on the
> wiki, but I do need to do something here in the short term since I need to
> listen to the browser-fired window online/offline events to implement the
> ONLINE_EVENTS exec bridge. How about just put in an android
> only work-around for now:
>
> cordova.addWindowEventHandler('online');
> cordova.addWindowEventHandler('offline');
> function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
> document.addEventListener('online', proxyEvent, false);
> document.addEventListener('offline', proxyEvent, false);
>
>
>
>
> On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> 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" <si...@gmail.com> wrote:
>>
>> >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 <ag...@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?
>> >>
>>
>>
Re: online events
Posted by Simon MacDonald <si...@gmail.com>.
This looks like a good thing to add in 2.2. We should get all the
other platforms to add the navigator.connection.network interface to
navigator.network as well to remain consistent.
Simon Mac Donald
http://hi.im/simonmacdonald
On Sat, Sep 1, 2012 at 11:26 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Figured out a work-around for clobbering things on navigator on Android
> (tested on 2.1 and 2.3):
>
> var newNavigator = {};
> newNavigator.__proto__ = navigator;
> newNavigator.__defineGetter__('onLine', function() {
> return network.type != 'none';
> });
> newNavigator.connection = {type: 'wifi'};
> window.navigator = newNavigator;
>
> I'll hook this up so that connection and onLine will work properly (woohoo!)
>
> As for events, I don't think document.body is common, but I think
> window.addEventListener is quite common since it works on both mobile
> safari and android browser. I'll add this to the API review list on the
> wiki, but I do need to do something here in the short term since I need to
> listen to the browser-fired window online/offline events to implement the
> ONLINE_EVENTS exec bridge. How about just put in an android
> only work-around for now:
>
> cordova.addWindowEventHandler('online');
> cordova.addWindowEventHandler('offline');
> function proxyEvent(e) { cordova.fireWindowEvent(e.type); }
> document.addEventListener('online', proxyEvent, false);
> document.addEventListener('offline', proxyEvent, false);
>
>
>
>
> On Fri, Aug 31, 2012 at 4:27 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> 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" <si...@gmail.com> wrote:
>>
>> >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 <ag...@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?
>> >>
>>
>>