Mislinked links in parentheses

[apiarian]

This toot https://toot.cafe/@sivy/99232447535117317 gets linked to https://(http//withknown.com/ instead of https://withknown.com. Looks like it’s something about finding a link inside parentheses and the leading parentheses getting mixed into it. The relevant part of the toot text is:

So... it seems to me like Known (http://withknown.com/) is a decent blog tool ...

[AlainODea]

Confirmed. I see this problem as well. It's come up in a few toots and I have to copy the link out of the embedded browser after visiting it and manually correct it.

Amaroq does not parse or link URLs correctly when they are preceded by punctuation or symbol characters.

I have a series of test cases in this thread:
https://infosec.exchange/@AlainODea/100261452240133300

Here they are for convenience to copy into test cases (I've replaced my domain with example.com):

Bare, no path:
https://example.com
Parens, no path:
(https://example.com)
Brackets, no path:
[https://example.com]
Braces, no path:
{https://example.com}
Comma, no path:
,https://example.com
Period, no path:
.https://example.com
Bare, root path:
https://example.com/
Parens, root path:
(https://example.com/)
Brackets, root path:
[https://example.com/]
Braces, root path:
{https://example.com/}
Comma, root path:
,https://example.com/
Period, root path:
.https://example.com/
Bare, ASCII path:
https://example.com/en/archives/2007/9
Parens, ASCII path:
(https://example.com/en/archives/2007/9)
Brackets, ASCII path:
[https://example.com/en/archives/2007/9]
Braces, ASCII path:
{https://example.com/en/archives/2007/9}
Comma, ASCII path:
,https://example.com/en/archives/2007/9
Period, ASCII path:
.https://example.com/en/archives/2007/9
Bare, ASCII path+query:
https://example.com/en/archives/2007/9?lang=en_CA
Parens, ASCII path+query:
(https://example.com/en/archives/2007/9?lang=en_CA)
Brackets, ASCII path+query:
[https://example.com/en/archives/2007/9?lang=en_CA]
Braces, ASCII path+query:
{https://example.com/en/archives/2007/9?lang=en_CA}
Comma, ASCII path+query:
,https://example.com/en/archives/2007/9?lang=en_CA
Period, ASCII path+query:
.https://example.com/en/archives/2007/9?lang=en_CA

The web UI from the Mastodon reference implementation renders all of these as the expected links (matching the bare examples above). Ironically (but cleverly in my mind), this relies on extract_entities_with_indices and extract_urls_with_indices from Twitter's Open Source twitter-text Gem.

I think Amaroq parses URLs from Toots using this:

Amaroq/Pods/ActiveLabel/ActiveLabel/RegexParser.swift

Lines 15 to 17 in 983ef5d

	static let urlPattern = "(^|[\\s.:;?\\-\\]<\\(])" +
	"((https?://|www\\.|pic\\.)[-\\w;/?:@&=+$\\|\\_.!~*\\|'()\\[\\]%#,☺]+[\\w/#](\\(\\))?)" +
	"(?=$|[\\s',\\|\\(\\).:;?\\-\\[\\]>\\)])"

That won't work beyond unambiguous, clearly isolated URLs in Toots. This isn't an easy problem to solve yourself, but you can use the Objective-C version of twitter-text. The Mastodon reference implementation does that, it's Apache 2.0 licensed.

I haven't touched Objective-C in over a decade or iOS programming at all yet, so the yak shave involved in me diving in here to fix this myself is very high. Normally, I would post a PR with a fix, not an issue. Hopefully, that's okay. Hopefully, my test reduction and identification of candidate libraries and corresponding solutions in other clients will help though.

[AlainODea]

Confirmed. I see this problem as well. It's come up in a few toots and I have to copy the link out of the embedded browser after visiting it and manually correct it.

Amaroq does not parse or link URLs correctly when they are preceded by punctuation or symbol characters.

I have a series of test cases in this thread:
https://infosec.exchange/@AlainODea/100261452240133300

Here they are for convenience to copy into test cases (I've replaced my domain with example.com):

Bare, no path:
https://example.com
Parens, no path:
(https://example.com)
Brackets, no path:
[https://example.com]
Braces, no path:
{https://example.com}
Comma, no path:
,https://example.com
Period, no path:
.https://example.com
Bare, root path:
https://example.com/
Parens, root path:
(https://example.com/)
Brackets, root path:
[https://example.com/]
Braces, root path:
{https://example.com/}
Comma, root path:
,https://example.com/
Period, root path:
.https://example.com/
Bare, ASCII path:
https://example.com/en/archives/2007/9
Parens, ASCII path:
(https://example.com/en/archives/2007/9)
Brackets, ASCII path:
[https://example.com/en/archives/2007/9]
Braces, ASCII path:
{https://example.com/en/archives/2007/9}
Comma, ASCII path:
,https://example.com/en/archives/2007/9
Period, ASCII path:
.https://example.com/en/archives/2007/9
Bare, ASCII path+query:
https://example.com/en/archives/2007/9?lang=en_CA
Parens, ASCII path+query:
(https://example.com/en/archives/2007/9?lang=en_CA)
Brackets, ASCII path+query:
[https://example.com/en/archives/2007/9?lang=en_CA]
Braces, ASCII path+query:
{https://example.com/en/archives/2007/9?lang=en_CA}
Comma, ASCII path+query:
,https://example.com/en/archives/2007/9?lang=en_CA
Period, ASCII path+query:
.https://example.com/en/archives/2007/9?lang=en_CA

The web UI from the Mastodon reference implementation renders all of these as the expected links (matching the bare examples above). Ironically (but cleverly in my mind), this relies on extract_entities_with_indices and extract_urls_with_indices from Twitter's Open Source twitter-text Gem.

I think Amaroq parses URLs from Toots using this:

Amaroq/Pods/ActiveLabel/ActiveLabel/RegexParser.swift

Lines 15 to 17 in 983ef5d

	static let urlPattern = "(^|[\\s.:;?\\-\\]<\\(])" +
	"((https?://|www\\.|pic\\.)[-\\w;/?:@&=+$\\|\\_.!~*\\|'()\\[\\]%#,☺]+[\\w/#](\\(\\))?)" +
	"(?=$|[\\s',\\|\\(\\).:;?\\-\\[\\]>\\)])"

That won't work beyond unambiguous, clearly isolated URLs in Toots. This isn't an easy problem to solve yourself, but you can use the Objective-C version of twitter-text. The Mastodon reference implementation does that, it's Apache 2.0 licensed.

I haven't touched Objective-C in over a decade or iOS programming at all yet, so the yak shave involved in me diving in here to fix this myself is very high. Normally, I would post a PR with a fix, not an issue. Hopefully, that's okay. Hopefully, my test reduction and identification of candidate libraries and corresponding solutions in other clients will help though.