A trailing dash/hyphen of an URL in an e-mail not "hyperlinked"
Categories
(SeaMonkey :: MailNews: General, defect)
Tracking
(Not tracked)
People
(Reporter: ant, Unassigned)
References
Details
User Story
e) Relevant RFC might be RFC 2396, RFC1034, 3.5, RFC 1738, sec 5 Still unclear: --------------- a) Same reason and roots for view effect in plain text email and message coding issue in html-email?
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 Build ID: 20171016030418 Steps to reproduce: 1. Compose a new e-mail to yourself. 2. Type an URL with an ending dash/hyphen like http://domain.edu/notreallocation-. 3. Save/Send it. 4. View that e-mail. Actual results: The hyphen/dash does not get hyperlinked in http://domain.edu/notreallocation- URL. This is without any fancy editing in the e-mail too. <http://domain.edu/notreallocation-> does include the ending dash/hyphen. Expected results: The ending dash/hyphen should had been hyperlinked as well for it to be clicked to work in the web broswer. FYI on how I discovered it: I got a new account validation e-mail that had an ending hyphen/dash that did not get hyperlinked. Clicking on it failed, but I noticed the issue. Copying and pasting with that ending dash/hyphen worked.
|
||
Comment 1•7 years ago
|
||
Effect is REPRODUCIBLE with unzipped installer of official en-US SeaMonkey 2.53a1 (NT 6.1; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Build 20170706013410 (Default Classic Theme) on German WIN7 64bit
a1) Composing plain text email I see the problem already in saved draft
Draft in source shows: "http://domain.edu/notreallocation-"
a2) Composing html email I see the problem already in saved draft
Draft in source shows: "<a class="moz-txt-link-freetext" href="http://domain.edu/notreallocation">http://domain.edu/notreallocation</a>-"
b) apparently same effect in TB Deily 56.0a1 (2017-07-30) (64-bit)
I sill do some more research later
@reporter:
Is 2.49.1 first Bad?|
|
||
Comment 2•7 years ago
|
||
c) no problem in HTML web page composer d) related to / DUP of "Bug 700991 - URL pattern matching ignores trailing dashes", which is a DUP of "Bug 414579 - URLs with trailing hyphens are improperly linkified" e) I wonder whether there are real life URLs with trailing "-"
Rainer, e) Yes, read my "expected results". I got an e-mail with a link like that yesterday with an new account creation on https://www.lancebase.com/ web site. Here is a changed URL from it https://www.lancebase.com/account-confirmation/888888/email?c=aKz88ocDzHla8u- . I don't know if SM v2.49.1 is the first version. It might had been around for years since this was my first time I ever saw an e-mail URL with its ending dash/hyphen before. Usually they are in the middle somewhere.
Amusing. Even Bugzilla won't hyperlink that last/ending dash/hyphen. :D
|
|
||
Comment 5•7 years ago
|
||
> Even Bugzilla won't hyperlink
f) Wordpress editor does not include trailing dash, too
|
||
Comment 7•5 years ago
|
||
I can confirm this issue in Thunderbird 60.7.0. Also, URLs ending with a hypen are used in practice, e.g. by Youtube as part of their video id (https://www.youtube.com/?v=[video-id]).
According to RFC 3986 (see page 49), hypens are unreserved characters and therefore might appear in the query part of an URL. Hence Thunderbird does not handle URLs correctly here.
From RFC 3986:
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
query = *( pchar / "/" / "?" )
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Still an issue in thunderbird-78.8.0. Zoom generates these types of links as well, this bug is quite annoying.
This bug is still present in version "102.3.1 (64-bit)". I get emails from confused users from time to time that the links don't work.
I think I have found out where the problem is: The hyphen is not considered part of the URL if the hyphen is followed by a newline. This may be behaving this way because TB is having trouble separating the newline from the recognition of the URI at that point.
The IETF (RFC 3986) talks about removing whitespaces from user-entered URIs for robustness. Perhaps this will fix the problem.
As a workaround, URLs can be provided with the angle brackets so that no whitespace appears after the hyphens (as Ant described in comment #0). Nevertheless, I see the need to fix this bug, as you can't expect innocent users to apply this workaround.
Description
•