356657 - On paste in editor, check for URL, and mark it properly

Status: NEW

(MailNews Core :: Composition, enhancement)

Description

[Ben Bucksch (:BenB)]

Idea triggered by bug 133016 and similar problems, where it's hard to detect the start and end of the URL in plaintext (the one problem of the recognizer). The idea is to add <> around URLs in plaintext and make them proper HTML links in HTML.

Base: Most URLs are copy&pasted during composition.
1. On paste, check whether it's a valid URL. This should be far easier
   and more precise than in the plaintext recognition, because we know
   the start and end.
2. If it's determined to be a URL, (with "foo" being the URL)
   - in HTML editor, insert
     <a href="foo" class="moz-txt-link-rfc2396E">&lt;foo&gt;</a>
   - in plaintext editor, insert
     <foo>
3. This results in:
   - If sent from HTML editor as HTML, a proper HTML link, no guessing
     involved from hereon anymore
   - If sent from HTML editor as plaintext, the HTML->TXT converter
     recognizes the class and won't mess with it, leaving only "<foo>"
     in the sent plaintext, thus same result as next case
   - If sent from plaintext editor as plaintext, it will sent "<foo>",
     which is far better to recognize than just "foo", because of start
     and end are better defined
     (bug 133016 and co, which triggered this idea)

Same for email adresses, just that they need special treatment:
- Our mailto: checker is practically non-existent, so we need to write
  checks. I have JS code for that, just need to know where to place it.
- they typically don't have the mailto: in front, so we need to add it
  for the href, but not the body text.

I can see only 2 potential problems:
1. A pasted text starts with a URL, but has other free text at the end, and our URL checkers don't bail on that. A solution is to simply not treat the paste in this special way, if any space is found in it.
2. How will other recognizers on the receiving side (not Mozilla) react on these <>? They are recommended in RFC2396 and RFC3986, but many braindead recognizers, e.g. in IRC chat app recognizers and sourceforce forums bail on it.
*However*, we already do send this out in several cases, e.g when you "insert|link" in the HTML editor and send as plaintext. I have not heard any complaints so far, so I think most recognizers in email are smart enough.

This is surely nothing for 2.0 branch, should bake on trunk.

Comment 1

[Ben Bucksch (:BenB)]

Another potential problem:
If we send as HTML, and some other client (not Mozilla-based) downconverts to plaintext (e.g. before/after send of reply) *and* it wants to output the link targets (hrefs) in the plaintext inline, then it might not recognize that href and link text are essentially the same, due to the added <> in the link text, and it may output the URL twice (once as href, once as link text). Again, I have not seen this in practice. It's a theoretical possibility, I ran into that when writing the converters, that's why I special-case the class.