All Things Techie With Huge, Unstructured, Intuitive Leaps

Issue with Cordova Framework and Apache-Tomcat

I have been having a major issue with Cordova framework for mobile app development.  To recap, when you press an HTML button, we have to transition from a web widget going to our server to an internal app screen that will handle a camera function.  The transition is made by having a fake url called "nextscreen" which is supposed to be trapped by a Javascript event listener in the app.  Instead of going to the scan screen, it goes to the domain index page.

The code used to go from the browser widget in the app looks like this:

              var browser = + '?uId=' + User.getId() + '&tkn1=' + User.getToken1(),
                '_blank', 'location=no,toolbar=no');

              browser.addEventListener('loadstop', function (event) {
                if (event.url.match(NEXT_SCREEN_URL_PATTERN)) {
                } else if (event.url.match(BACK_URL_PATTERN)) {
                } else if (event.url.match(LOG_OUT_URL_PATTERN)) {
                } else if (event.url.match(FULL_SITE_URL_PATTERN)) {
         + '?uId=' + User.getId() + '&tkn1=' + User.getToken1(), '_system');

A Javascript event listener is attached to the browser widget and matches the URL pattern and it is supposed call /camerafunction.  Instead it goes to the welcome/index page in the domain -- in our case either the test server and/or the prod server.  There is a proviso.  We upgraded from Tomcat 7.0.21 to 7.0.56 and that seems to be the issue.  Whenever I regress the server back to 7.0.21, the app works.

I am intrigued that when the app works on 7.0.21, we get a little flash of the index page, and then the app goes to /camerafunction.  In 7.0.56, it is somehow trapped at the index page.  The reason that it is intriguing, is that there is nothing in the code to suggest that it should go to the domain welcome page, yet it does, and always has, albeit for just a second.

I ran extensive test to pinpoint the issue.  The match phrase for trapping is ".*nextcamera.*".  What I thought was happening was that the new server was being aggressive and recognizing the fake url.  If that was the case, then it should have thrown a 404 not found error.  I even tried that by putting garbage into the fake url, and it still took me to the domain welcome or index page.

Then I was wondering if perhaps an error on the index page interrupted the redirect from the Cordova web widget to the app /camerafunction screen, so I swapped out the index page for a single word -- a "Hello World" index page if you will. Nada.  So it doesn't throw 404 errors, and it doesn't hang up on the domain index page.

The next step was to upgrade the Tomcat to the latest series rev 7 server.  I downloaded and deployed Tomcat 7.0.57.  Nada. Same deal.  Then I wondered if perhaps some config were causing it.  So one by one, I went through and not only diffed server.xml, but context.xml, web.xml, noweb.xml and finally I got ticked off and substituted the entire $TOMCAT_HOME-7.0.21/conf to the latest.  Still buggy.  Regressing back to 7.0.21 again, and it worked.

I fired up the Mac Powerbook to see if the issue was the same with iOS.  It is.  I ran it in debug in XCode and didn't see anything - including in the console.

I downloaded Google Chrome Canary to do a device inspection, but the only Android device that I have is an older Samsung Galaxy, and even enabling it for USB debugging, Chrome couldn't find the device.

There is no way that we can go back to Tomcat 7.0.21 because of security holes.  What I find totally weird, is why and how the index page comes up with the event listener URL intercept. That is totally baffling to me.  There is nothing in the code to even suggest that this should happen. Since this behavior happens in the non-buggy, working server version and the later non-working version, something has to be happening in the app, otherwise we would be throwing 404 errors. The JRE (Java Runtime Environment) is the same, and even if it wasn't, an event listener should behave the same way regardless of the JRE.

I still haven't solved this one. If you have run into this before, and have solved it, please leave a comment. Educated guesses welcome.

No comments:

Post a Comment