pull down to refresh

5 sats \ 6 replies \ @sox 26 Mar

Okay this is getting really interesting, on Brave the link text is not preserved ... but on Safari it is?

I'll check what's going on. Maybe the outlook 'safe' links are the culprit?

reply

On my PC (brave) it happens, I’m not sure what it could be, but if I swap the '.' for ',' the error doesn’t happen.

a far more optimistic look than the OPM’s [11.1 percent](https://www.census.gov/library/publications/2024/demo/p60-283.html) from the same year.

a far more optimistic look than the OPM’s [11,1 percent](https://www.census.gov/library/publications/2024/demo/p60-283.html) from the same year.
reply
5 sats \ 4 replies \ @sox 26 Mar

On Brave, in `compose` mode, everything seems fine. Our markdown conversion pipeline shouldn't differ between browsers, but on Safari this bug doesn't happen.

I'll keep investigating.

reply
128 sats \ 3 replies \ @sox 26 Mar

Okay I think I got what's happening here, the clue is:

but if I swap the '.' for ',' the error doesn’t happen anymore.

We check for misleading links, stuff like [google.com](bing.com) and we replace the 'misleading' link with [bing.com](bing.com). You know, to keep it fair.

But the way we check for misleading links seems to differ between browsers. For Safari, https://11.1 percent is of course not a domain and not even a URL; for Chromium https://11.1 percent is instead a perfectly valid URL and will trigger the misleading link replacement.

We need to make the check more clever.

reply

Great!

Solution: make your own function to check for valid links! ~lol

reply
5 sats \ 0 replies \ @sox 26 Mar

lmao the problem is that it's our own function that's doing this, we rely on browser's URL detection to do our checks but maybe we shouldn't rely on it that much.

reply