[
https://issues.apache.org/jira/browse/CB-14234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16563833#comment-16563833
]
Dan Polivy commented on CB-14234:
---------------------------------
[~jcesarmobile]: I can't differentiate the URL in handleOpenURL, because it
*could* be a legitimate URL the app can handle, but in *this case* I want it to
open in the system browser, not the app. It's weird to me that the syntax of
window.open(url, "_system") would even attempt to open in the app – by
specifying the target as "_system" that's a pretty explicit statement you want
it to open in the system browser.
For my purposes, not sending handleOpenURL for http/https should address this,
as we do check the incoming URL to validate it before handling it. Other
schemes (aside from our custom scheme which launches the app) should be ignored.
I'm curious, though, under what scenario is it expected to call handleOpenURL
on the app when trying to open a URL (http/https or otherwise) in the system?
> InAppBrowser iOS calls handleOpenURL in same app for _system URLs
> -----------------------------------------------------------------
>
> Key: CB-14234
> URL: https://issues.apache.org/jira/browse/CB-14234
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-inappbrowser
> Affects Versions: 3.0.0
> Reporter: Dan Polivy
> Priority: Minor
>
> The change to fix CB-11178 has caused some undesirable behavior with
> InAppBrowser on iOS. Now, whenever you try to open a URL in the system
> browser, by calling `cordova.InAppBrowser.open(url, "_system")`, it opens the
> system browser AND calls `handleOpenURL` _in your app_ with the same URL.
> In my case, my app is a URL handler for a corresponding web domain (app
> links). I am trying to open a page on this web domain in the system browser
> from within my app. If my app's handleOpenURL is called with a URL also on
> the domain, then my handler thinks it is handling an app link and it causes
> the app to navigate to another URL, which in this case is not desired or
> expected.
> Prior to the fix for CB-11178, this worked perfectly. Is there any other way
> to address the fix for CB-11178 without inheriting this incorrect and
> undesirable behavior?
> [~jcesarmobile]: FYI as you committed the fix in question.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
