iOS 11 force touch on links opens pages in Safari!

I am posting this here to alert others, and I will file an Issue on this. I am not going to make a support request, because I have a workaround that works-out better for us anyway as it has other benefits. (I will describe the work-around).

Since iOS 11, (edit: I think actually 10?) there is a new feature in Safari (and also in at least WKWebView - have not tested UIWebView) where if you force-touch on a link (or button with link) the browser (or webview) will load the page and present a preview window. If you apply additional force, then it will open the new document in the browser.

The problem in Rhodes, though, is that it is not opened in the WkWebView! It will be opened in Mobile Safari.

I should note my rhoconfig.txt settings. I use:

# Do not use curl for network, because Apple requires IPV6 capability for App Store, and curl does not support it
ios_net_curl = 0

# While I would prefer to use ios_direct_local_requests, it is currently not possible unless using curl for networking
ios_direct_local_requests = 0

# My app does not require this
ios_https_local_server = 0

# Use WKWebView for good performance
ios_use_WKWebView = 1

I do not know what force touch on a link would do with different settings. For example, I might guess that with ios_direct_local_requests = 1 either it will not be an issue, or if would still launch but get a 404 error (since no exposed server). It would be helpful if others report their findings.

Of course, opening the page in Safari will expose the server port number, inviting examination and hacking of the Javascript side of the app. Anyone then can debug using Safari desktop remote inspection/debugging, even if inspection/debugging of the app's webview is disabled. As well, for most Rhodes apps, the functionality of the app probably will not work within mobile Safari. (For example, a controller might navigate the webview, but this will not navigate Safari.)

Additionally, the page request made upon initial moderate force touch may have unintended consequences in your app. (Because now the controller has been called by the server in order to fetch the page.)

Here's a relevant Issue from another project which I think has some information on how Rhodes might be able to disable this using an iOS SDK:

github.com/turbolinks/turbolinks-ios/issues/95

----
Workarounds:

1. I presume there is some -webkit CSS for Safari that will disable this. I'm guessing some new value for pointer-events: I haven't pursued this. It might be a quick fix.

2. Just don't use default browser behavior for links. This is my chosen work-around, as our app already doesn't use default browser behavior for MOST links. That is, use Javascript event registration, and then make a call to prevent default action (in jQuery, e.g.  event.preventDefault() ). Actually, I started using interact.js event callbacks and have some centralized code dealing with buttons/links with various options given as CSS classes or data- attributes. It makes use of the pointer events API if available, and gives you more options for interaction. I have a few "natural links" lingering yet, though, and that's how I noticed this.

----
It might be nice if Rhodes can support this behavior internally (but needs to be configurable to disable it). But definitely should not be opening pages in the browser upon navigation! (I open some pages in Safari intentionally, but I use System.openUrl for that).