WKWebview allowsLinkPreview to false breaks text selection
Asked Answered
T

2

6

We have an app that uses WKWebview, but sets allowsLinkPreview to false because we don't want link preview behavior. It seems that starting with iOS 13.4, on devices that don't have 3D touch functionality (older devices and newer iphone models), setting allowsLinkPreview to false also disables all text selection in the page! For our app, text selection is critically important.

I came up with this theory reading between the lines in the documentation:

In iOS this property is available on devices that support 3D Touch.

On devices running iOS 13 and later, people can use the touch and hold gesture to open a context menu, regardless of whether the device supports 3D Touch. On 3D Touch devices, the gesture can reveal the context menu more quickly.

It seems like a bug that disabling link preview disables all press and hold gestures in the webview.

The only workaround I've been able to come up with is to set allowsLinkPreview to true, and then disabling the context menu via the WKUIDelegate protocol. This disables the popup for clicked links, but does not disable the popup for clicked images. And, it still allows users to drag-drop the link into a split screen view in safari, which we do not want.

Any suggestions for how to completely disable link preview/context menu/drag-drop behavior while still allowing text selection would be appreciated!

UPDATE
Since I control the content of my app, I was able to disable press-hold of images by using the following css: -webkit-touch-callout: none; So my remaining problem is just to disallow drag interactions out of the app from the WKWebView.

UPDATE 2 Similarly, I was able to use -webkit-user-drag: none; to disable dragging of links, but it would still be useful to know a non-css fix for what seems to me like an Apple bug.

Tracay answered 8/4, 2020 at 17:36 Comment(0)
C
3

This may be related to a known Webkit bug that is presumably already fixed (as of this writing):

https://bugs.webkit.org/show_bug.cgi?id=210191

Car answered 24/4, 2020 at 22:9 Comment(3)
That indeed looks exactly like my bug. Thanks.Tracay
Do we know when these get fixed?Flinders
I do not. I presume that is up the sole discretion and prioritization of Apple.Car
M
2

I encountered the same problem, and this is how I solved it.

wkwebview.UIDelegate = self;

...

- (BOOL)webView:(WKWebView *)webView shouldPreviewElement:(WKPreviewElementInfo *)elementInfo API_AVAILABLE(ios(10.0)) {
    return NO;
}
Mahalia answered 19/4, 2020 at 17:44 Comment(2)
Thanks for the response. I think I tried that, but I can't be sure. Since that API is deprecated, I was using the modern replacement webView(_:contextMenuConfigurationForElement:completionHandler:), which I would have thought would have equivalent behavior. I'll have to give this a try and see if it would be an alternate solution to the problem.Tracay
@JonBrooks Did you get it to work with webView(_:contextMenuConfigurationForElement:completionHandler:) ?Eva

© 2022 - 2024 — McMap. All rights reserved.