The problem is the multiple document.addEventListener duck punch calls, and mismatching callbackIds.
Checking 'window.cordova' is not really a hack imho, that is where we export to. We can re-eval if we ever hear of it actually happening. Also, a window.onerror handler reveals the issue immediately, I will document this more, plus it will tell you where your extra colon or comma is ... More evidence this should be user-space, documentation and 3rd party tooling. > On Mar 17, 2015, at 7:01 AM, Carlos Santana <csantan...@gmail.com> wrote: > > I agree with Joe this looks like a User space problem. > But in this particular case, I would say that if cordova.js is ran a second > time cordova.js should be robust and no errors no side effects should > happened. > > checking with window.cordova, that feels like a hack, I would I agree a > good hack :-) > > I would say that for now adding the quick check is valid solution, but I > would open another JIRA issue for future deep investigation on the root > cause of running cordova.js: > - Is the problem in cordova.js code that is core? > - Is the problem in plugin js code that gets run by cordova.js core? > - Is the problem in 3rd party plugin js code that gets run by cordova.js > core? > > > > > On Mon, Mar 16, 2015 at 3:13 PM, Horn, Julian C <julian.c.h...@intel.com> > wrote: > >> Well, I can see that this is kind of a philosophical disagreement. >> >> Today having two <script> tags for cordova.js is defined to be an error. >> As such the current behavior of cordova.js is correct. But you could just >> as well have said that it's not an error. I think that's a better choice. >> >> I've spent most of my career working on software development tools for >> various languages. Generally we try to minimize uncheckable constraints or >> "gotchas" when we can. This makes things a little harder for a few tools >> vendors and a little easier for large numbers of developers. That's >> usually an easy decision to make. >> >> When you create a new Cordova project in the Intel XDK, we provide a >> template that includes a script tag for cordova.js. This means the only >> way you can lack the tag is if you delete it (or import a project that was >> missing the tag). That's a great thing: it makes it much less likely that >> users will forget to include cordova.js and wind up wasting hours looking >> for an explanation. >> >> However, the opposite mistake does still happen. People don't read the >> entire template (why should they?) and think they have to add the tag >> themselves. That's how new users sometimes get into this situation. We >> would like that not to be an error; it just makes things a little smoother >> and more forgiving, which is our goal. >> >> I will certainly submit a pull request. >> >> Julian >> >> -----Original Message----- >> From: Joe Bowser [mailto:bows...@gmail.com] >> Sent: Monday, March 16, 2015 1:36 PM >> To: dev@cordova.apache.org >> Subject: Re: Introduction for Julian Horn >> >> On Mon, Mar 16, 2015 at 6:40 AM Horn, Julian C <julian.c.h...@intel.com> >> wrote: >> >>> >>> The fix certainly does not require a large chunk of time! Here's the >>> entire fix; you put this up near the top of cordova.js, inside the >>> outermost function invocation: >>> >>> if (window.cordova) { >>> return; >>> } >> And nothing is stopping you from issuing a pull request. While Jesse and >> I think that we shouldn't get into the practice of fixing people's JS >> errors, I'm sure that someone in this project might agree with you. I just >> don't think it's a bug, or even an improvement. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org > > > > -- > Carlos Santana > <csantan...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
