[
https://issues.apache.org/jira/browse/CB-11097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15286503#comment-15286503
]
Daniel Åberg edited comment on CB-11097 at 5/17/16 12:34 PM:
-------------------------------------------------------------
I tested this recently and it seems to work without any issues during my short
testing session.
I also tested another approach I found on stack overflow that also worked ok.
It just adds this above "if ([self.allowIntentsWhitelist URLIsAllowed:url
logFailure:NO])"
{noformat}
if ([self.allowNavigationsWhitelist URLIsAllowed:url]) {
// the url is in the <allow-navigation> tag, so we can navigate
to this url
return YES;
}
{noformat}
http://stackoverflow.com/questions/34320758/allow-navigation-whitelist-is-not-tested-first-on-uiwebviewnavigationtypelinkcl
I have to research this more before I use any of these solutions in production
and there is also the problem with the remote build server downloading this
with npm, so any change in Visual Studio will not be copied over, am looking
into if it could be copied over with a hook.
was (Author: dajje):
I tested this recently and it seems to work without any issues during my short
testing session.
I also tested another approach I found on stack overflow that also worked ok.
It just adds this above "if ([self.allowIntentsWhitelist URLIsAllowed:url
logFailure:NO])"
if ([self.allowNavigationsWhitelist URLIsAllowed:url]) {
// the url is in the <allow-navigation> tag, so we can navigate
to this url
return YES;
}
http://stackoverflow.com/questions/34320758/allow-navigation-whitelist-is-not-tested-first-on-uiwebviewnavigationtypelinkcl
I have to research this more before I use any of these solutions in production
and there is also the problem with the remote build server downloading this
with npm, so any change in Visual Studio will not be copied over, am looking
into if it could be copied over with a hook.
> Clicking hyperlink in an iframe opens a system browser instead of navigating
> to it
> ----------------------------------------------------------------------------------
>
> Key: CB-11097
> URL: https://issues.apache.org/jira/browse/CB-11097
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS, Plugin Whitelist
> Affects Versions: 6.0.0, 6.1.1
> Environment: Cordova 6.1.1, iOS platform 4.1.1, developing in Visual
> Studio 2015 with remote build server. Affects Cordova 6.0.0/iOS 4.0.0 and
> later. Same behaviour on simulator and physical phone.
> Reporter: Daniel Åberg
> Labels: ios, triaged
>
> From Cordova 6.0.0/iOS platform 4.0.0 and newer there is a change in behavior
> or bug that stops navigating an anchor tag/hyperlink to an external site from
> working.
> If you have an iframe with a page with an anchor tag in which an href that
> points to for an external domain it will now open it in the system browser
> instead of loading it in the iframe.
> It seems to have something to do how it handles if it’s going to navigate or
> open in a new browser.
> If you have the this in your configuration file you get this behavior:
> <access origin="*" />
> <allow-navigation href="*" />
> <allow-intent href="http://*/*"; />
> <allow-intent href="https://*/*"; />
> If the allow-intent tags are removed, the iframe will load the page in the
> href, so it seems like it first checks the intents and if its allowed it is
> then opened in a new system browser regardless of other configuration.
> This is a change in behavior, Cordova 5.4.1/iOS 3.9.2 navigated unless you
> used InAppBrowser window.open() with target _system to open in the system
> browser.
> I have tried this with and without having Whitelist and InAppBrowser plugins
> installed, I also tried the Cordova WKWebView Engine and got the same
> behavior so I think it must be something in the iOS platform.
> This issue might be related to the issue reported in CB-10709
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
