Commit Graph
3 Commits
Author SHA1 Message Date
mrsdizzieandtechknowlogick f2de5dc8c8 Replace linkRegex with xurls library (#6261)
* Replace linkRegex with xurls library

Rather than maintaining a complicated regex to match URLs for
autolinking, gitea can use this existing go library that takes care of
the matching with very little code change to gitea itself. After
spending a while trying to find the perfect regex for all cases this library
still works better as it is more flexible than a single regex ever will be.

This will also fix the following issues: #5844 #3095 #3381

This passes all our current tests and I've added new ones mentioned in
those issues as well.

* Use xurls.StrictMatchingScheme instead of xurls.Strict

This is much faster and we only care about https? links to preserve
existing behavior.
2019-03-07 15:12:01 -05:00
mrsdizzieandtechknowlogick 020075e12f Remove visitLinksForShortLinks features (#6257)
The visitLinksForShortLinks feature would look inside of an <a> tag and
run shortLinkProcessorFull on any text, which attempts to create links
out of potential 'short links' like [[test]] [[link|example]] etc...
This makes no sense because you can't have nested links within an <a>
tag. Specifically, the html5 standard says <a> tags can't include
interactive content if they contain the href attribute:

 http://w3c.github.io/html/single-page.html#the-a-element

And also defines an <a> element with a href attribute as interactive:

 http://w3c.github.io/html/single-page.html#interactive-content

Therefore you can't really put a link inside of another link. In
practice none of this works anyways since browsers won't render it, it
would probably be broken if they tried, and it is causing a bug
(#4946). No current tests rely on this behavior either.

This removes the feature and also explicitly excludes the
current visitNodeForShortLinks from looking in <a> tags.
2019-03-07 14:13:44 -05:00
mrsdizzieandLunny Xiao 4a2e92bcd1 Modify linkRegex to require http|https (#6171)
Modify the current linkRegex to require http|https which appears to be
the intended behavior based on the comments. Right now, it also matches
anything starting with www as well. Also add testing for linkRegex
2019-02-28 20:31:53 +08:00