The current implementation doesn't play well with URLs that contain a trailing dot: https://example.com/users/example. is wrongly parsed as https://example.com/users/example and https://example.com/users/example? is, too, wrongly parsed as: https://example.com/users/example The relevance of the latter case is debatable, since in URLS, "?" commonly only serves as a delimiter in front of the GET arguments. So, not parsing it shouldn't make a difference to the URL pointed to. The period, on the other hand, makes a drastic difference, since this is a quite common character allowed in usernames for a lot of websites. Since most RESTful websites have URL schemes such as `/users/${username}`, this completely breaks the ability to freely link to your user page (which is how I found this bug). Reproducible: Always Steps to Reproduce: 1. Open a KTp conversation. 2. Send a URL to somebody that ends with "." or "?". Actual Results: The characters "." and "?" aren't parsed, although they are valid URLs. Expected Results: The parser should match these characters, too.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.