The link field in profiles does not show scheme, and adds extraneous `/` at the end
d
drewbabe
started a topic
12 months ago
So, this is a double-pronged bug report, but I didn't want to start two whole new threads for what is essentially probably coming down to the same piece of code in the backend.
So, first off, let's talk about the scheme in the URL, or rather, the lack thereof. I think it is either a bug or a misguided feature that profile links do not show the scheme. While `https://` is going to be the most common scheme by far, I actually have a valid use case for using `http://` in my profile link (I bought a domain purely to register redirects to my socials and such, and some browsers seem to not like it if I use `https://` with those links, so I use `http://`instead.) However, it's completely reasonable for users to expect secure connections, and while most browsers have some sort of built-in indicator that warns you if you're browsing a site that doesn't have a secure connection, they don't always warn you before you actually first load the page. Users should have a right to be able to anticipate an insecure connection, so the best way to make sure it's always telegraphed is to just display the scheme. I did not want to make this a feature request because I believe it's kind of a given, and because the next part of my post is something that I believe is being done intentionally but which actually causes bugs.
Secondly, the extraneous `/` suffix that gets added: I'm not an expert with web stuff, but doesn't it add the risk of changing the meaning of the link? Also, it's an eyesore when there is no scheme displayed. Anyway, let's give examples of what behavior I am talking about: if I type `http://drewbabe.net` into the link page, it gets rendered as `drewbabe.net/` and the href attribute is `http://drewbabe.net/`. That's not what I want, I want what I typed to be what shows up. And I don't think it's just a me problem, since you can even see this on the @staff account, which shows their link as `assc.notion.site/` with the href attribute being actually `https://assc.notion.site/`. Again, I'm not an expert with web stuff but it does impact the meaning of URLs apparently, so this may cause unexpected and unavoidable behavior for some people. This applies especially if you ever start letting people use links that aren't HTTP(S) (thinking primarily of ipfs:// URLs, which, if you have a local gateway running, are more secure than going through a third party's HTTPS gateway.)
All in all, I would like to suggest that the behavior the user should experience should be something like this:
If the user types a fully formed URL with a proper scheme, where the scheme is something you want to support and allow people to have links to, then it should display as they typed it.
If the user types just a domain (and maybe a path) then they should either get an error telling them to include the scheme, or it should default the scheme to `https://` (the most likely correct choice.) And, the link should display that scheme.
If the user types something that is not even part of a valid URL, they should get an error.
BTW, in case this is a browser-related bug that wouldn't happen in, say, Safari or Chrome: I am using Firefox 109.0.1 on macOS 13. The only add-ons I have that affect cohost are uBlock Origin and uMatrix but I don't think any domains I've blocked have any effect on how the site is displayed. I also have Stylus with the Cohost Theme Customizer style added, but I checked that disabling it does not fix the problem (and I don't think it has the capability to do something like that anyway.)
drewbabe
So, this is a double-pronged bug report, but I didn't want to start two whole new threads for what is essentially probably coming down to the same piece of code in the backend.
So, first off, let's talk about the scheme in the URL, or rather, the lack thereof. I think it is either a bug or a misguided feature that profile links do not show the scheme. While `https://` is going to be the most common scheme by far, I actually have a valid use case for using `http://` in my profile link (I bought a domain purely to register redirects to my socials and such, and some browsers seem to not like it if I use `https://` with those links, so I use `http://`instead.) However, it's completely reasonable for users to expect secure connections, and while most browsers have some sort of built-in indicator that warns you if you're browsing a site that doesn't have a secure connection, they don't always warn you before you actually first load the page. Users should have a right to be able to anticipate an insecure connection, so the best way to make sure it's always telegraphed is to just display the scheme. I did not want to make this a feature request because I believe it's kind of a given, and because the next part of my post is something that I believe is being done intentionally but which actually causes bugs.
Secondly, the extraneous `/` suffix that gets added: I'm not an expert with web stuff, but doesn't it add the risk of changing the meaning of the link? Also, it's an eyesore when there is no scheme displayed. Anyway, let's give examples of what behavior I am talking about: if I type `http://drewbabe.net` into the link page, it gets rendered as `drewbabe.net/` and the href attribute is `http://drewbabe.net/`. That's not what I want, I want what I typed to be what shows up. And I don't think it's just a me problem, since you can even see this on the @staff account, which shows their link as `assc.notion.site/` with the href attribute being actually `https://assc.notion.site/`. Again, I'm not an expert with web stuff but it does impact the meaning of URLs apparently, so this may cause unexpected and unavoidable behavior for some people. This applies especially if you ever start letting people use links that aren't HTTP(S) (thinking primarily of ipfs:// URLs, which, if you have a local gateway running, are more secure than going through a third party's HTTPS gateway.)
All in all, I would like to suggest that the behavior the user should experience should be something like this: