Close method not working and showing ambiguous console warning

I am trying to implement OAuth with BrowserTab, I have successfully opened a BrowserTab with .openUrl() and also implemented deeplinks and through that its successfully opens my app and my app continues to work, I am able to pass on the control to my app in Android , But in iOS deeplinks works fine but my app continues in background only BrowserTab remains on foreground and i am trying to close the BrowserTab through close() method it doesn’t work and says:

I am using chrome inspector

here is my code snippet:

public selectTracker(id) {
  id = parseInt(id)
  let url;
  switch(id) {
         case 1 : url = 'http://oauth1.com/';
           break;
         case 2 : url = 'http://oauth2.com/';
           break;
    }

  this.browserTab.openUrl(url);

  (window as any).browserTab = this.browserTab;

  setTimeout(()=>{ // <--- I tried this as well 
      this.browserTab.close();
  },1000);
}

Seems like there is problem with the BrowserTab API since console warning doesn’t make sense, I tried removing and installing the plugin again doesn’t work.

Also, how should I go about closing the BrowserTab if this isn’t the correct way.

[heberallred]

We had the same issue with OAuth with BrowserTab until we did a custom URL scheme which for some reason closes the tab when called.

So instead of: window.close(); try myapp://close Note: replace “myapp” with the custom URL scheme of your own app. You set this up using a package such as “cordova-plugin-customurlscheme”.

We’ve had instances where we have to call this twice to get it to close for some reason. The /close part of the custom URL has no known significance, but the “myapp://” part of the URL somehow triggers your app and closes the BrowserTab.

[heberallred]

@ltlbsteed on our team actually found this solution in an article somewhere, and implemented it into our code. I figured I would post here for the benefit of anyone who is trying to solve this issue because it can use up a lot of time to solve. If the main thread of the program didn’t freeze while the BrowserTab is open, then it would be a non-issue because the main thread could close it, but for now this is the only work-around we’ve found.