Greater-than character swept up into link when followed by a period

[boredzo]

The auto-linkification system, upon detecting a bracketed bare URL (e.g., < http://adiumx.com/>), sometimes sweeps up the > as part of the link.

This occurs whenever the > is followed by:

• ‘.’
• ‘!’
• ‘?’
• ‘<’
• ‘>’

Examples:

• It's at < http://adiumx.com/>.
• Oh, you mean < http://adiumx.com/>!
• Are you sure you typed < http://adiumx.com/>?
• < http://adiumx.com/><><><><> [final > is optional and is not included in the link if present]
• < http://adiumx.com/>>>>>>>> [final > is not included in the link]

Similarly, when the ‘<’ is preceded by a ‘>’, the ‘<’ is assimilated into the link. In the case of one link immediately after another, such as “< http://adiumx.com/>< http://adiumx.com/>”, one big link is formed between the outer <>.

 The syntax specification for URLs and  the syntax specification for HTTP both specify that neither ‘<’ nor ‘>’ is a valid character in a URL pathname.

[boredzo]

Clarified last example by adding a […] note.

[edr1084]

I'm unable to reproduce this so I'm assuming you fixed it in:

(In [20361]) Fixed #7161 by allowing all characters above 0x7f, except 0xf5?\226?\128?\1470xff (which Unicode says don't occur in UTF-8 sequences), in the hostname of a URL. RFC 1738 and RFC 2396 only allow alphanumeric characters here, but it's not possible to fix this ticket and be strict about only allowing alphanumerics, because flex doesn't know Unicode.

[zacw]

It looks like the examples work now, unless the / is excluded from the URL.

For example: < http://www.adiumx.com/>! is linkified, but not < http://www.adiumx.com>! and any other end character (., ?, >, <).

[jas8522]

with r21197 the examples that zac provides behave like:

< http://www.adiumx.com/>! is indeed linkified but the linkified part is  http://www.adiumx.com/> which is not good
< http://www.adiumx.com>! nothing is linkified.

This was tested with MSN and Gtalk though it shouldn't matter.

[evands]

6 months goes beyond the statute of limitations on ticket ownership for a buglet. I get bug!

[evands]

(In [23057]) Trim off all invalid opening or trailing characters, not just the first we find. Fixes #7267

[evands]

(In [23058]) Merged [23057]: Trim off all invalid opening or trailing characters, not just the first we find. Fixes #7267

[boredzo]

(In [23061]) Added unit tests for SHHyperlinkScanner. Refs #7267, and partially disproves r23057. Two of these tests fail.

[boredzo]

(In [23062]) Merged r23061 from [source:/trunk trunk]: Added unit tests for SHHyperlinkScanner. Refs #7267, and may partially disprove r23058. Two of these tests fail.

[boredzo]

Reopening because I derived the test cases in r23061 and r23062 from this ticket, so the two that fail mean that this ticket is not yet fully fixed.

(BTW: I love unit testing.)

[eharris]

Fair enough, not really sure this was a UI bug anyway, which is why I claimed it since I like those and all.

[evands]

(In [23063]) Properly trim the whole set of invalid characters, not just a subset of them. Fixes #7267, and all tests now pass.

[evands]

(In [23064]) Reverted [23063], which was clearly not what I meant to commit. Refs #7267

[evands]

(In [23065]) Properly trim the whole set of invalid characters, not just a subset of them. Fixes #7267, and all tests now pass.

[evands]

(In [23066]) Merged [23065]: Properly trim the whole set of invalid characters, not just a subset of them. Fixes #7267, and all tests now pass.

[boredzo]

(In [23067]) Added test cases for the rest of the characters that nextURLFromString: may trim. Refs #7267.

[boredzo]

(In [23068]) Merged r23067 from [source:/trunk trunk]: Added test cases for the rest of the characters that nextURLFromString: may trim. Refs #7267.