<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - AutoCorrect: Writer not recognizing a URL's trailing carat, hash mark, question mark, backslash, or pipe" href="https://bugs.documentfoundation.org/show_bug.cgi?id=91192#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - AutoCorrect: Writer not recognizing a URL's trailing carat, hash mark, question mark, backslash, or pipe" href="https://bugs.documentfoundation.org/show_bug.cgi?id=91192">bug 91192</a> from <a class="email" href="mailto:Nick_Levinson@yahoo.com" title="Nick Levinson <Nick_Levinson@yahoo.com>"> Nick Levinson</a> <pre>The backslash should be accepted for another reason: If I type a URL with an incorrect backslash directly into certain browsers, the browser changes the incorrect backslash into a correct slash. Examples in Firefox 84.0.2 (64-bit): <a href="http:\\slashsleep.com">http:\\slashsleep.com</a> loads <a href="http://slashsleep.com/">http://slashsleep.com/</a> and <a href="http://slashsleep.com\3\you-will-sleep\1\sleep-always-wins.html">http://slashsleep.com\3\you-will-sleep\1\sleep-always-wins.html</a> loads <a href="http://slashsleep.com/3/you-will-sleep/1/sleep-always-wins.html">http://slashsleep.com/3/you-will-sleep/1/sleep-always-wins.html</a> (that's my website and I don't have an alias or redirection set up for the backslashes so either the browser or the hosting server is doing it for all URLs). This fails but shouldn't: <a href="http://example.com?age=293">http://example.com?age=293</a> . However, this is properly hyperlinked in LO Writer: <a href="https://example.com/?age=293">https://example.com/?age=293</a> . The sole difference is in the slash after the TLD; I'm not sure if a server could be configured to accept the slashless version, so LO should hyperlink it, just in case. I favor recognizing characters that are questionable in URLs on the same principle that early on applied to emailing: be strict in what you send but generous in what you accept. LO should generously recognize a typist's text as a URL with the boundaries being spaces or angle brackets. The worst that can happen is failing to arrive at the URL when clicked and even that can be corrected in the browser's address bar, which is easier for nongeeks than figuring out what should have been in the URL in the LO document. This example uses a nonexistent TLD and yet is generously hyperlinked as a URL by LO Writer: <a href="http://google.quibble">http://google.quibble</a> Parentheses, square brackets, and pipes (unfamiliar to me as a URL boundary but here accepted arguendo) can be identified as URL boundaries if they appear spacelessly both before and after the string that otherwise is a URL. Examples: (example.com), [<a href="ftp://example.com">ftp://example.com</a>], and |example.com| . However, spacelessness must be at both ends; if it's at only one end, I don't know exactly what should be hytperlinked. Angle brackets are already known to be boundaries. While <<a href="http://example.com">http://example.com</a>> properly hyperlinks in LO without hyperlinking the angle brackets, <example.com> does not hyperlink in LO, but should. A comma following a URL's directory, file, query, fragment, or slash should be treated as part of the URL because the host's server might recognize it. But a comma-and-space following an apparent TLD should be treated as not part of the URL, although it's too burdensome to have LO check if a domain label is a known or actually proposed TLD listed at iana.org or icann.org. If a URL ends with a TLD, it may be followed by a period or not without changing the URL. (I forgot which RFC says so.)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>