External links no opening new browser window

I’m suddenly seeing some odd issues when I try and link to an external file (PDF). If I map to a website URL it seems to work just fine, however when I map to say a PDF it will not work.

I have a click handler to use window.open(“url”) but both android and IOS will not honor the link. No error messages, just seems to ignore the link request. However if I use just a regular URL like https://google.com it will open a new browser window just fine…

Any ideas?

Edit: Check that the remote url isn’t in trusted_urls for your app’s config.json. Both Android and iOS launch an external browser just fine for me when I use pdf urls.

That said, the Android WebView has never supported opening PDF’s. It will happily take your request and just ignore it.

One workaround folk have used is to open pdf’s with Google Docs. e.g. see this StackExchange question: Unable to open PDF documents in WebView

Weird that it’s not working for iOS though as I don’t have any issues with it.

Do you see anything in the verbose forge logs?

Have you tried looking at it with the Safari remote debugger?

Hi Antoine,

Its very bizzar and digging into it a bit more it looks like any https link will not work, however if its http it will…

Our config is set to allow any URL’s through because the nature of the app could link out to any URL (user generated content)

That being said this is the normal flow of things

$(document).on(“click”,".myLink",function(){
window.open(“http://google.com”)
})

This will work, and opens a new browser window outside the app

$(document).on(“click”,".myLink",function(){
window.open(“https://google.com”)
})

Will not work, and is ignored by IOS and Android

Currently, the workaround we are using is to push all links to a http redirect page that take the URL they would like and redirects them to it, however the initial open is using http as to open a new browser window.

So when you try the scenario above does it work for you?

It explains things partially if you’ve set trusted_urls up to accept anything.

On Android it will just sit there and nothing will happening for pdf’s because the Android WebView does not support pdf.

If the url was not in trusted_urls then Forge would have sent the link to the operating system to handle which should then open an external viewer if the device has one.

On iOS, however, it should open the pdf inside the WebView.

If the factor here is http vs https it may be certificate related? Are the certificates on the remote url’s valid? Are you seeing any errors if you use verbose logging with forge run ios -v ? Do you see any error messages if you attach the Chrome or Safari remote debuggers?

Do you think you could put together a simple standalone app and send me the config.json, index.html and main.js files so I can try reproduce the issue on my side?

So I spun up a sample project and it looks to be an issue with my trusted URLs… so weird…

Let me ask this question. I have seen issues where loading things in via an iframe would not work unless I explicitly added it in for things like youtube, vimeo etc. I need to allow all URL’s because we will not know what the URLs may be (user generated).

I added * to the list, this causes the app to crash

If we add https://* and http://* causes the page to load in the same context as the app, breaking the application.

So how can we ensure our iframes will work but also jump users out of the app when its an external link?

@scthi probably has more insight on this than me but you’re running into one of the fundamental issues we’ve had with WebView development.

The problem is that from the Forge runtime side we have no way of telling whether a link is being triggered from a parent frame or an iframe so your trusted_urls settings are going to apply to both.

I’m wide open to suggestions if there’s anything I can do from the runtime side!

would it not be possible to use classes to determine how longs should act? We use framework7 as a ui / ux / template engine. With FW7 to have links jump out and not route you must use ‘link external’ in the class list of the href?

Secondly, what if there was a specific forge.open command? We use window.open in JS this is basically telling the links that we wish to open a new browser window, but if there was a way to tell forge we want a new browser to open then it may work.

Third option may be to build a specific forge.iframe module, this would allow forge to know how to handle the URL.

Our use case may be a bit different as we use the ‘Iframe’ specifically for loading video / livestream URL’s and ‘links’ should be allowed to open in a new browser window unless using the child browser window.

As it stands right now, the way we have to work around this is to have a redirect script that passes all URL’s through our http redirect script so all external links are contructed as

< a href=“http://ourserver.com/redirect?url=https://urltoopen”>link< /a>

I’m wondering, if as mentioned above if something on the forge side say forge.open(url, target) could work. The underlying module could then take that URL, force a new browser window with the URL. I would expect this to not use the trusted URL’s as its simply a passthrough to a new site maybe have an option to honor trusted_urls if needed.

On the flipside, the same logic could be used for something like forge.iframe(src, properties) this would essentially do the same thing but would tell forge its an iframe vs a link.

I’m not opposed to constructing links or iframes in a different way, however it would need to fallback on webview as we use both web and ios / android builds.

1 Like

I can’t do much from our side to help with iframe modules and/or DOM-driven solutions as we don’t get any special access via native code.

That said, this I can do:

You can track it here:

Nice! Thanks Antoine! Looking forward to… when does it drop :smiley: