Parsing differences between NcRichText and Reference API lead to inconsistent link previews

[provokateurin]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Post a message https://example.com
2. Post a message [abc](https://example.com)
3. See the messages:
   

Expected behaviour

All links should be recognized both in the text and the previews below the message.

Actual behaviour

The NcRichText correctly recognizes the embedded markdown link, but the Reference API doesn't and thus no preview is shown below.

Talk app

Talk app version: main

Browser

Operating system: Arch Linux

Browser name: Firefox

Browser version: 132

I know strictly speaking this is a problem with the Reference API in server, but I filed it here in Talk because I noticed it here and in general I think it is the most impacted place and the devs should be aware of this.
Feel free to move the issue to server, if you feel it is more fitting there.

[ShGKme]

If this is an issue - it is nextcloud-vue's NcRichText component's issue.

[nickvergessen]

Please open in the vue lib (can't move across orgs)

[provokateurin]

If this is an issue - it is nextcloud-vue's NcRichText component's issue.

I don't think so. The regex for resolving references does not handle the closing parenthesis of an embedded link so there is no resolved reference extracted from the test when running the regex on it.

To explain it a bit more:
I hit the exact same problem in my own implementation and wanted to check if the web frontend handles it correctly, but it also doesn't show the link preview.
I only use the regex to extract the links for the references from the message.
Given that the behavior of these different implementations is the same it must be the regex.
I'm sure the same happens on iOS and Android if they also use the reference regex for the previews.

[provokateurin]

Ok, after having a closer look I understand why you're saying this is a nextcloud-vue and not server problem.

I fixed it both in nextcloud-vue and server:
nextcloud-libraries/nextcloud-vue#6224
nextcloud/server#49334

Unfortunately nextcloud-vue uses a hardcoded version of the regex instead of using the one exposed by the capabilities, but at least they are in sync at the moment, so it had to be fixed twice.
I don't know if any of the official clients are actually using the regex exposed by the server, but they should do that and not hardcode it like nextcloud-vue does.