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