I think it makes sense to have this be an option since it's breaking ff. I think it's actually only required now by the cordova-plugin-network-information plugin.
1. Maybe we could just move it into that plugin? 2. Or, we could make it a separate plugin that others wanting to override navigator symbols can depend on. 3. Or, we could move the logic into modulemapper such that the hack is applied only when clobbering a symbol on navigator doesn't take hold. On Thu, Aug 8, 2013 at 7:10 AM, Richard Sentino <[email protected]>wrote: > Hello > > I just wanted to keep the ball rolling about this issue. > > In response to "SecurityError be caught in an try{} block?", yes and it > seems to do the trick. At the moment, out of the FirefoxOS-specific APIs it > gets stuck in the mud at "mozTime" [1] which is only available to certified > apps [2] therefore a security error will be thrown [3]. With the recently > refactored cordova-js, do you guys have any intention on clobbering > navigator at the platform.js level ? I made a test app [4] running on 3.0.x > from master branch and tested on FirefoxOS 4.0/5.0pre simulator and on a > Keon device. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=751011#c3 > [2] > https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozTime > [3] > https://github.com/apache/cordova-js/blob/master/lib/common/init.js#L56 > [4] http://rixrix.github.io/cordova-firefoxos-patch/manifest.webapp > > Thanks > > -- > Richard > > > On 25/06/2013, at 8:25 AM, Andrew Grieve <[email protected]> wrote: > > We also used this to implement navigator.connection. Without this, we can't > replace the connection property. Another example is the onLine property for > Android. It needs to be overridden to hide the fact that it is toggled > on/off by our exec() bridge. > > > On Mon, Jun 24, 2013 at 3:59 PM, Gord Tanner <[email protected]> wrote: > > > This might be a bad example since most platforms support native > geolocation > > now but I know we would run into problems with: > > > > navigator.geolocation = require('cordova/plugin/geolocation') > > > > When geolocation already existed on navigator it would throw a security > > exception (or just be a noop). It is the cost of doing our shit on the > > navigator object, every platform treats this as a "secure" object > > (rightfully so) and does things a little differently. The lowest common > > denominator was to just dump our own mock object in ASAP to prevent a lot > > of that security stuff from getting in our way. > > > > Does this still need to happen? (I don't know) > > What platforms were having problems? (I can't really remember) > > Should we look into if we still need to do this? (of course) > > > > the bootstrap.js is ment to contain code for bootstrapping all of cordova > > on every platform. I am thinking we may need to rethink the navigator > > clobbering and make this a platform overridable bootstrap step. > > > > > > > > On Mon, Jun 24, 2013 at 3:50 PM, Brian LeRoux <[email protected]> wrote: > > > >> But wait, and I'm serious here, why even duck punch navigator to begin > >> with? > >> > >> I understand we add properties to it. Is that why it needs to be opened? > >> > >> On Mon, Jun 24, 2013 at 11:50 AM, Ian Clelland <[email protected]> > >> wrote: > >>> Can the SecurityError be caught in an try{} block? If so, then we could > >>> implement a general solution of "try to clobber the entire object; if > >> that > >>> doesn't work, try to clobber each of its properties instead." > >>> > >>> In the second case, a debug log line for each property that cannot be > >>> copied would give us a list of any platform-dependent quirks that we > > need > >>> to document. > >>> > >>> > >>> On Mon, Jun 24, 2013 at 2:42 PM, Gord Tanner <[email protected]> > > wrote: > >>> > >>>> This is from the bootstrap file for all platforms [1]. > >>>> > >>>> This is to cover us for security issues we were having on other > >> platforms > >>>> where we are not able to replace existing navigator object methods > >>>> (geolocation, etc) or add new ones. We create this object and proxy > > to > >> the > >>>> original navigator object to have something that is a bit more > > flexible > >> for > >>>> us to work with and modify. > >>>> > >>>> Does firefox yell at us if we replace the navigator object without > >>>> iterating over the old one? We could then just hardcode the list of > >>>> functions to proxy over to the original for that platform. > >>>> > >>>> [1] - > >>>> > >>>> > >> > > > https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob_plain;f=lib/scripts/bootstrap.js;hb=HEAD > >>>> > >>>> > >>>> On Mon, Jun 24, 2013 at 2:34 PM, Brian LeRoux <[email protected]> wrote: > >>>> > >>>>> I'm at a loss why that code even needs to exist. > >>>>> > >>>>> Anyone? Herm / Gord? > >>>>> > >>>>> On Thu, Jun 20, 2013 at 5:06 AM, Piotr Zalewa <[email protected]> > >>>> wrote: > >>>>>> I came to a point where I need to use the group wisdom. > >>>>>> > >>>>>> In > >>>>> > >>>> > >> > > > https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5929Cordovaistryingtoreplace > window.navigator with something which looks > >>>>> like a copy of itself. window.navigator is protected in FirefoxOS - > >> even > >>>>> browsing through its properties is not allowed. > >>>>>> > >>>>>> alert('pre'); for (var key in window.navigator) > >>>> {window.navigator[key]}; > >>>>> alert('post'); > >>>>>> > >>>>>> Above code will work in browser, but not on the device or > >> Simulator. It > >>>>> will throw "SecurityError: The operation is insecure." and 'post' > > will > >>>> not > >>>>> get alerted. Example in JSFiddle - > >>>>> http://jsfiddle.net/zalun/VkCyH/embedded/result/ (just install in > >>>>> Simulator) > >>>>>> > >>>>>> I'm looking for a solution for that issue. > >>>>>> > >>>>>> Is the step with replacing window.navigator needed? The comment in > >> the > >>>>> code says > >>>>>> // We replace it so that properties that can't be clobbered can > >> instead > >>>>> be overridden. > >>>>>> > >>>>>> > >>>>>> Piotr > >>>>> > >>>> > >> > > > >
