Yep, I verified your change fixes the failure with Ripple (in fact, just the 'window.cordova' check is enough to fix Ripple, since that returns undefined).
________________________________________ From: Jesse <purplecabb...@gmail.com> Sent: Tuesday, May 5, 2015 10:53 AM To: dev@cordova.apache.org Subject: Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple Discussions aside, are you in a position to test ripple? I believe this change will fix it, can you try this change, and I will look into the ripple side shortly? https://github.com/apache/cordova-js/pull/109 We can start the re-release fanfare in the morning, as a minor release directly from the last release and a minor bump with no other changes coming in. Let me know if there are still issues in cordova-js, and I'll look later tonite. Cheers, Jesse @purplecabbage risingj.com On Mon, May 4, 2015 at 5:23 PM, Tim Barham <tim.bar...@microsoft.com> wrote: > Thanks Jesse... > > > but still it will be at least a week before we can get a new everything > out > > And the alternatives will take less than a week? :) > > While I agree there may be better ways for Ripple to "do it's thing", my > immediate concern is to get Ripple working as quickly as possible. If we > can indeed kill those two birds with one stone, that's great, but I'm > worried that anything beyond a simple fix will drag out for quite a while. > > Also, I was picturing these sorts of changes as being part of proper > plugin simulation support built into Cordova (that is, the ongoing project > I've mentioned previously) - I wonder if for now we should just fix this > the quickest way we can, and make sure the appropriate, public, documented > hooks are in place as part of that project. > > > override the entire cordova object > > BTW, I guess you already know this, but to make sure it is clear - Ripple > doesn't override the cordova object - it only overrides cordova/exec. It > intercepts the creation of the cordova property so it can immediately patch > cordova/exec before it can get called by anyone. It seems to me that > patching cordova/exec is pretty fundamental to how Ripple works, but if > there was another way it could ensure the correct timing (that is, patch > cordova/exec after the cordova object is created, but before it can ever > get called), that would probably suffice. > > I don't think cordova/exec/proxy is going to be a viable solution (at > least as it currently works) - isn't there the risk that that will get > overridden by plugins themselves? Also, Ripple wants to intercept *any* > cordova.exec call, even ones it doesn't know about (so it can display UI to > handle those cases) - how to we handle that using cordova/exec/proxy? > > Thanks for looking into this, BTW. > > Tim > > ________________________________________ > From: Jesse <purplecabb...@gmail.com> > Sent: Tuesday, May 5, 2015 9:57 AM > To: dev@cordova.apache.org > Subject: Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple > > Yeah, my reasoning is that it is difficult to update all the affected bits > in cordova. We can change the cordova logic, but still it will be at least > a week before we can get a new everything out. > > Part of my reasoning is that ripple claims to be a '... platform agnostic > mobile application development and testing tool.' We should make that part > true as well. > > Personally, I consider ripple's use of 'cordova' to be risky given that we > have certain expectations of how our own library works, which may or may > not be private to cordova. I would much rather see ripple implement a > ripple-cordova connector class which uses cordova/exec/proxy or some > cordova apis that we purposely publish, which is what I plan to look into > this week. Or we can consider moving to a model where we do define a way to > override the entire cordova object, and document it. > > > @purplecabbage > risingj.com > > On Mon, May 4, 2015 at 3:56 PM, Tim Barham <tim.bar...@microsoft.com> > wrote: > > > Hey Jesse - is your reasoning behind that to avoid having to release an > > update for Cordova tools + all platforms, or because you don't want to > > change the existing Cordova logic (and if the latter, what's your > concern)? > > > > Have you had any inspiration about how to fix Ripple to avoid tripping > > this? I've not been able to come up with a safe approach yet. On the > other > > hand, the change in Cordova to avoid triggering this is very simple - > just > > a pain that it requires releasing a bunch of updates. > > > > Tim > > ________________________________________ > > From: Jesse <purplecabb...@gmail.com> > > Sent: Saturday, May 2, 2015 2:28 AM > > To: dev@cordova.apache.org > > Subject: Re: Cordova 5.0.0 "duplicate cordova" check breaks Ripple > > > > I think ripple will need to change, I'll have a look and see if there is > a > > more elegant way to implement honeypot. > > > > > > > > > On Apr 30, 2015, at 7:06 PM, Tim Barham <tim.bar...@microsoft.com> > > wrote: > > > > > > Hey everyone - a bug was filed today against Ripple that it is broken > > with > > > Cordova 5.0.0. The issue is that Ripple triggers the new "duplicate > > > cordova" check: > > > > > > cordova-js/src/cordova.js line 22: > > > if ("cordova" in window) { throw new Error("cordova already > > defined"); }; > > > > > > Ripple patches cordova by defining a setter for window.cordova to > > > intercept it being created. This is sufficient to make ("cordova" in > > > window) return true. I don't see a way to readily resolve this issue in > > > Ripple. We can fix it in Cordova by changing the test to: > > > > > > if (window.cordova) ... > > > > > > Couple of questions: > > > 1. Any reason not to make this change? > > > 2. To get this fix out will require re-releasing all platforms, > correct? > > > And I presume a tools release to update the pinned platforms? Is this > > > sufficient reason to trigger such a release? > > > > > > Thanks! > > > > > > Tim > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
