javascriptphonegap-pluginsphonegap-buildchildbrowser

PhoneGap Build ChildBrowser plugin issue on iPad - Reopens after close


I am using PhoneGap Build version 2.9.0, with official PG plugin ChildBrowser (v4.2.1).

Background: I'm using ChildBrowser for OAuth purposes - authenticating to a 3rd party application. Basically, once the user authenticates I detect a specific url, close the ChildBrowser, and move on.

However, this is what occurs on the iPad only (iPhone and Android work fine): - ChildBrowser launches on 3rd party app's auth screen - User approves my app, is redirected to placeholder page on my website - ChildBrowser closes (as expected), but then reopens immediately to [placeholder page].com/index.html. - This takes up the whole screen and user is unable to continue.

Here is my code:

window.plugins.childBrowser.onLocationChange = function(location) { 
   if (location.indexOf('oauth_verifier') > -1) { 
     window.plugins.childBrowser.close(); 

     // code removed - retrieve and store oauth value from url (location variable) 
     // code removed - get access token via 3rd party API 

     navigator.notification.alert('Success!'); 

     // send user to Activity tab 
     window.location.href = "index.html#tabstrip-activity"; 
   } 
  } 
};

childBrowser.showWebPage("www.linkTo3rdPartySiteAuth.com");

What I believed was happening was that the browser was closing as desired, but then it gets to the line where I set the window.location back to index.html, causing either PhoneGap or the iPad to launch an incorrect index.html page. However, I tried removing that line that changes the window location but the issue still occurs. Thoughts?


Solution

  • I've resolved the issue: the line in which I set window location seems to be the problem. I believe that PhoneGap Build didn't update the app correctly the last time I tried removing it. Subsequent tests have been successful though. I'm still a bit confused as to why this happens here and not in other locations where I have the same behavior - my best guess is that it's because it falls within the onLocationChange method.