__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 <agri...@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 <f...@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.macdon...@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 <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?
> >> >>
> >>
> >>
>
