When swiping to scroll through a post in the Reader, it shouldn't matter where you place your finger to perform the swipe action.
If you happen to place your finger on a link when you perform the swipe action, it opens the link instead of scrolling the post.
This is especially troublesome because you can't immediately close the webview. While the webview says "Loading..." the "x" in the top left doesn't do anything.
Result: No matter how quickly you perform the swipe action, the link opens.
The current implementation is a bit of a hack. We're intercepting the delegate call that asks if the text view should interact with a specific link and presenting it there. This probably worked before, but changed on iOS 13.
Luckily there's a new API to customize those interactions: https://developer.apple.com/documentation/uikit/uitextinteraction
I've been digging into this issue a lot in the past couple of days and don't have a solution yet.
The UITextView delegate method shouldInteractWith URL gets called on scrolling (which I assume didn't happen before iOS 13) and so the range it catches is big and includes the link attribute.
I tried removing that method and instead implement func gestureRecognizer(_ gestureRecognizer: UIGestureRecognizer, shouldReceive touch: UITouch) -> Bool
Where I checked the gesture and extracted the link from the attribute by the touch location and that doesn't seem to work either. The recognized gesture seems to be a Pan gesture for both scrolling and tapping (weird) and so I couldn't treat those differently:
```
func gestureRecognizer(_ gestureRecognizer: UIGestureRecognizer, shouldReceive touch: UITouch) -> Bool {
let point = gestureRecognizer.location(in: self)
let characterIndex = self.layoutManager.characterIndex(for: point, in: self.textContainer, fractionOfDistanceBetweenInsertionPoints: nil)
let attributeName = NSAttributedString.Key.link
let attributeValue = self.attributedText?.attribute(attributeName, at: characterIndex, effectiveRange: nil)
if let value = attributeValue,
let url = value as? URL,
let richDelegate = self.delegate as? WPRichContentViewDelegate{
richDelegate.interactWith?(URL: url)
}
return true
}
```
^ gets called when scrolling and recognizes a link (especially in a heavy link post like: https://5blogs.wordpress.com
@koke , any suggestions on how to proceed here?
Just found this:
https://stackoverflow.com/questions/58189447/ios-13-uitextview-delegate-method-shouldinteract-called-when-scrolling-on-attach
Going to try the suggestion there
FWIW, I have spotted the same issue in Apple’s own Settings app.
If the new APIs aren’t working, I’m not sure what’s the right approach here. We want to change how we act on a link when we tap on it, but not the interaction itself. The multiple gesture recognizers make sense because on first touch, you could be initiating a tap, a long press, or trying to scroll.
The stack overflow workaround seems fragile but could work until we figure out the new APIs? 🤷🏽♂️
I tried. It doesn't work reliably unfortunately :(
I'm a bit concerned about the SO example, because there's not just one tap gesture recognizer:
(lldb) po textView.gestureRecognizers!.filter({ $0 is UITapGestureRecognizer }).map({ $0.name! })
▿ 4 elements
- 0 : "UITextInteractionNameDoubleTap"
- 1 : "UITextInteractionNameSingleTap"
- 2 : "UITextInteractionNameLinkTap"
- 3 : "dragAddingItems"
It seems UITextInteractionNameLinkTap is the one that we would want to override. There's no clean way to do this, but I'm wondering if instead of the shouldInteractWithURL: API we should override that one UITextInteractionNameLinkTap gesture recognizer. It is messing with private APIs, but it's probably no worse than what we're doing now.
From a 1-star review "Long Time User, Not Anymore" by TMC28 – Oct 2, 2019 Version 13.2.3
I've used the WordPress app on my iPhone 7 for years without issues. Since the ios 13 updates, it's become nothing but annoying. I can't scroll any article that include links of any kind, without those links loading. What's really bad is no matter how gently I scroll past those links, they still load 90% of the time. Annoyingly, it takes 2 or 3 presses on the back button to escape the various links. I read mostly political sites with tons of links.
Thanks @designsimply , I'm updating my PR according to @koke's review and will add a line on fix to the release notes, targeting 13.3.
Fixed in https://github.com/wordpress-mobile/WordPress-iOS/pull/12612. Props @yaelirub. 🎉