Link underlining breaks if the link is edited within the middle of the text (or in some other cases)

[MetaflameDragon]

Describe the bug This seems like a really far-reaching bug with a lot of extra cases, but I'll try my best. Each time I returned to test further, I found more weird behavior.

In the post compositor, returning the cursor to a link not at the end of the text, and either editing it or appending text, causes all the extra text to get underlined, including whitespace and URL-incompatible characters. Newline at the end of the link is an exception, but not when inserted into the middle. Pasting from Bluesky, other browser tabs, or external sources all produces different results (elaborated below)

I couldn't repro this on mobile - the text field seems to re-parse pasted links correctly and extra text added onto a link doesn't get underlined.

This appears to be an entirely client-side visual discrepancy, and only before a post is sent.

To Reproduce

1. Write a new post with a link in the middle of the text
2. Return your cursor to the link, into the middle or to the end of it, and start typing further
3. All newly-typed characters - except for a newline if at the end - will be underlined too
4. Pasting non-link text from the compositor keeps it as a non-link. Pasting another link from the text field, even a subsection, keeps that subsection linked to the url that it came from. Pasting text copied from some other sources (e.g. notepad, but not the browser) behaves one way or another, some formatting correctly, some extending the link incorrectly.
5. Deleting the link never invalidates it in this case either, not until it's deleted completely. This is also evident by the interface suggesting a card for the link until all the blue underlined text from it is erased.

Additionally, this also occurs when, after writing a link at the end of a post:

• Hitting enter, then backspace, then typing more
• Deleting at least one character from the link (at any point, even after erasing previous text ahead of the link), then typing more
  • The card suggestion only gets invalidated after
• Pasting text copied from certain sources
  • Copying from notepad extends the link (even if it starts with a newline)
  • Copying from elsewhere in the browser, even another tab, keeps links or plain text, even if the links were hrefs that then don't get parsed after posting (that is, blue text that doesn't match its target url).

Expected behavior

• When pasting any text, link/underline behavior should be consistent with how the server parses it after posting. Currently, links are only valid when they write out the whole link, but the client/app shows the underline even when the server won't put it there afterwards.
• When editing a link in the middle of text (or, as mentioned, at the end after making a newline and, it should be re-parsed correctly on the frontend. Non-URL characters should invalidate links if inserted, or end links if appended. Likewise with deleting parts of links currently, as they aren't invalidated until removed entirely.
  • Since rich text is probably gonna eventually support completely custom linking, this behavior should still be consistent with user expectations. If I type example.com into my post, and then erase the last part to make it say example.org, my link should lead to the latter, but right now the client suggests that it leads to the former. The server re-parses it as expected currently, but this expected behavior should be ensured for directly-written links if/once full rich-text linking is supported. Modifying text with a link shouldn't change the link, but modifying an auto-generated link should auto-regenerate the link too. (if that makes sense)
• Overall, the text compositor should be in sync with how the server parses the post after it's sent

Screenshots

Details

• Platform: Desktop, Chrome 115.0.5790.171 (Official Build) (64-bit) (cohort: Stable)
• App version: 1.47.0

Additional context

I discovered this while reporting #1292, and testing it yielded a lot of weird edge cases. Feel free to refer to a thread where I tried out various things: https://bsky.app/profile/metaflame.bsky.social/post/3k5wu6gboov2o The server side of things seems to handle everything properly, though I raised concerns there about a potential typo-squatting exploit with links and non-matching cards; that's for another Issue though.

[intrnl]

Link handling in composer is handled differently between web and mobile versions.

It's very finicky on the web because of the plugin it's currently using to get that underlining effect. https://tiptap.dev/api/marks/link

Most importantly whether or not the underlining happens doesn't actually reflect what will be sent on the post, because the client does an additional parsing of its own, independent of what the WYSIWYG editor does, and that's what actually makes it into the post.

Commenting this to give more context as to what's happening within the post composer.

[pfrazee]

Yep yall are sniffing out the root of the problem. There's a mismatch between the link plugin's behavior and our intended behavior.

Luckily I've got something from my larger sideproject to replace the editor that we can use here. It's a custom plugin that just decorates text based on regex matches. I'll pull in that piece to fix this for now.