RocketChat
Links without schema point to #
Description:
Links without schema are clickable, but the link target is #.
Steps to reproduce:
- Submit a message containing a link without schema (e.g.
example.com). - Observe that
example.comis parsed as a link. - Click on the link.
Expected behavior:
A new tab opens which shows http://example.com (as http should be the default schema if none is specified).
Actual behavior:
A new tab opens which shows the instance Rocket.Chat where you come from.
Server Setup Information:
- Version of Rocket.Chat Server: 7.7.0
- License Type: Starter
- Number of Users: 23
- Operating System: Debian GNU/Linux
- Deployment Method: Docker
- Number of Running Instances: 1
- DB Replicaset Oplog: enabled
- NodeJS Version: whatever is in the Docker image
- MongoDB Version: 7.0.21 / wiredTiger (oplog Enabled)
Client Setup Information
Apparently the issue appears in every browser on every operating system, including the Electron client. However, I just successfully reproduced the issue on:
- Desktop App or Browser Version:
- Firefox 139.0.1 (64-bit)
- Chromium Version 137.0.7151.68 (Offizieller Build) Arch Linux (64-Bit)
- Operating System: Arch Linux
Additional context
I think this is a regression introduced in one of the most recent versions of Rocket.Chat. Alas, I don't know in which one.
Tried on 7.6.3 on a Macbook with FF 139.0.1 and it works fine
Hover over the links and it shows:
//example.com
Click and it opens:
https://example.com/
I am not aware of any other method to prevent showing link previews in specific messages, so being able to post links without a schema is important to us.
I am not aware of any other method to prevent showing link previews in specific messages, so being able to post links without a schema is important to us.
This has nothing to do with this issue. More likely this one (and possibly other duplicates if you search)
https://github.com/RocketChat/Rocket.Chat/issues/7734
Which is fixed as far as I can see in 7.6.x and probably earlier.
admin/settings/Message, Embed Link Previews Whether embedded link previews are enabled or not when a user posts a link to a website.
It has everything to do with this issue. There is no feature to remove link previews on SINGLE messages (not all messages in an entire channel or on the server). As thus, posting links without a schema was the only workaround to do exactly that.
Sure, I could be posting a feature request to allow a user to remove the link previews from their single message, but keep in mind this needs to be something an integration must also be able to do. Instead, how about links without schemas getting fixed first, as this has properly omitted link previews by both users and automations.
In theory, this is actually another bug (no link preview shown on links without a schema). But this is a bug that we are happily and often exploiting, because it gives us a feature that otherwise doesn't exist.
We love being able to post link previews, but not always. Here is an example of how we make use of links without a schema, so that users don't need to scroll up two pages to read the actual post, while still allowing link previews by default:
So please fix this, it is important to us and probably others (@paulchen ?) who knew about this trick. We use it daily.
It has everything to do with this issue.
No it does not.
Please read what this bug is about, not what you want it to be about.
This issue is urls render to '#'. That's it. Nothing else.
The team know about this specific issue. It will get fixed as and when they choose.
There is no feature to remove link previews on SINGLE messages
Again, that has nothing to do with this bug.
Sure, I could be posting a feature request to allow a user to remove the link previews from their single message
So you have clearly demonstrated you know this is nothing to do with this issue. You have described exactly what you should do.
So please fix this,
This is open source, not free support on demand.
If you have a paid version contact them directly.
If not please either use an appropriate existing issue, or create a new feature request for setting link preview statuses.
Of course they'll be happy to look at your PR.
This is the xth time I am running into you.
Once again you have clearly demonstrated that you did not understand my first post (I said specific message, not all messages), as I explain why this feature (which is now broken) is of actual use to someone and possibly more important to fix than someone might think on first sight. You had also tested with the wrong version when the original author stated the version clearly.
Then you lecture me how I am wrong and point me to irrelevant configuration directions. Then I explain to you how i am not wrong and try to explain to you better, and the best you come up with is lecturing me again. Have you considered "ah, interesting, I see how you make good use of this" instead of acting outright unfriendly?
I have not requested your support. I have asked to please fix this, as it is more important than people might think on first sight (such as you did obviously), giving a real world example. As you saw yourself I do understand the entire scenario, and as such I also understand that fixing this issue eradicates a) this bug, URLs pointing to # b) regains a feature that otherwise would need to be implemented. So what I am requesting is nothing but the easiest solution, after having added extra information underlining why this feature is of actual use to someone.
Why I have come here and used my lifetime to comment on this issue is to demonstrate that this bug is not almost irrelevant but that people rely on this for something you believe has nothing to do with the actual bug, which is true, but it underlines the severity of this issue has raised slightly. Which you will have understood in case you understand the scenario too.
I have not come here to get into yet another discussion with you. I've not come here to learn from you about my understanding of the world. There was no reason yet again to get an attitude. The last thing you will gain with your attitude is someone to consider a paid version. Maybe stop lecturing others, you're not a bouncer, your attitude does not improve this project. Stay friendly.
PS. And this discussion has now ended. I will not comment any further.
This is the xth time I am running into you.
Yup. Probably though not sure where as you have almost zero github activity.
Unfortunately for you I'm about the only community person who triages bugs here, and have elevated permissions. I work closely with the team, and have for nearly a decade. If I wasn't about you would be almost entirely ignored unless you had paid support.
If you want help or something fixed you would do well to consider your language, not just to me, but everyone.
I am not in interested in opinion and personal abuse. Just the facts to relay to the team.
Once again you have clearly demonstrated that you did not understand my first post (I said specific message
Your first post referred to link previews. It is irrelevant in this context.
Regarding testing I needed to try and understand exactly when it was introduced hence I tested originally on 7.6 and then unbeknown to you on 7.7 which is when I reported it to the team internally.
Hence:
I'll ask the team to look.
And the 'Tasked' label. That means it has been referred internally and the team will review it.
There is no feature to remove link previews on SINGLE messages (not all messages in an entire channel or on the server)
I have asked to please fix this, as it is more important than people might think
This issue is links incorrectly rendering to #
That's it. Nothing about rendering link previews, or removing them individually. I have told you - that what you want is a "feature" as you state ie a NFR. That's it. Open a new issue as a feature-request in the correct repo.
Note also you might think this feature is important, but the team may not. As I said. PRs are a welcome.
Stay friendly
I am not here to purposefully annoy people, but many don't like what they are told. The code is released as open source, not "free software", or "free" in any sense.
I am here to triage bugs and cut the wheat from the chaff so we don't waste devs time and have a better chance of getting an issue fixed.
Rocket.Chat has its own commercial priorities and github is at the bottom of the list. People who are not paying clients are joint equal at the bottom of that list.
Those who open clear well documented issues, those who contribute code, and those who help, are more likely to get listened too. Those demanding features or fixes will not.
I look forward to seeing you help here, in the forums and on open as well.
In the meantime, Paul I have chased this issue with the team internally - it is with Core currently.
Thank you.