Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WKWebView allowLinksPreview should be set false, or user-settable #922

Open
jtara opened this issue Nov 8, 2017 · 0 comments
Open

WKWebView allowLinksPreview should be set false, or user-settable #922

jtara opened this issue Nov 8, 2017 · 0 comments
Assignees

Comments

@jtara
Copy link

jtara commented Nov 8, 2017

With iOS10, Apple defaulted WKWebView allowLinksPreview property to true.

This means that in a WKWebView, force touch on a link will first open a preview, and then with more force, will open the link.

However (at least in Rhodes) this opens in Safari browser rather than in the app. At least for the case of ios_direct_local_requests = 0. (I have not tried, but guess that if 1, it would try to open and get a 404 error in Safari, since no real server.)

For almost all cases, it is probably not desirable for this to be true in Rhodes. Opening in Safari will expose the server port, and invite examination and hacking. Even if it were to open within the Rhodes app WKWebView, it will often lead to unintended consequences, because in order to get the preview, then the request is made and the server calls the controller.

There might be cases where a developer wants to take advantage of this behavior, but it would almost certainly have to be enabled on a case-by-case basis for each link, and in any case would normally need to open within the app WkWebView, not in Safari. Developer would have to be aware of the consequences of the controller method call needed to fetch the preview and take it into account to insure no unintended side-effects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants