> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as you think. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) and a number of other variations. You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is *not* fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. Can you please answer my question? What is inserting the links here? Is `scanHTML()` being used? If not, why not? That's the bug here.
Bug 1692771 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as you think. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) and a number of other variations. You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is *not* fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. What is inserting the links here? Is `scanHTML()` being used? If not, why not? That's the bug here.
> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as you think. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) and a number of other variations. (Please note that bugzilla mis-reconizes the links here. Our `mozTXTtoHTMLConverter.scanHTML()` does this better.) You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is not fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. What is inserting the links here? Is `scanHTML()` being used? If not, why not? That's the bug here.
> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as you think. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) and a number of other variations. (Please note that bugzilla mis-reconizes the links here. Our `mozTXTtoHTMLConverter.scanHTML()` does this better.) You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is not fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. Which code is inserting the links here in this case during HTML email composition, if the user does not explicitly mark the URL as link? Is `scanHTML()` being used? If not, why not? That's the bug here.
> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as you think. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) and a number of other variations. (Please note that bugzilla mis-reconizes the links here. Our `mozTXTtoHTMLConverter.scanHTML()` does this better.) You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is not fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. Which code is inserting the links here in this case during HTML email composition, if the user does not explicitly mark the URL as link? Is `scanHTML()` being used? If not, why not? That's the bug here.
> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as that. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) and a number of other variations. (Please note that bugzilla mis-reconizes the links here. Our `mozTXTtoHTMLConverter.scanHTML()` does this better.) You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is not fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. Which code is inserting the links here in this case during HTML email composition, if the user does not explicitly mark the URL as link? Is `scanHTML()` being used? If not, why not? That's the bug here.
> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as that. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> ($1 != $2) * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> ($1 != $2) * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) ($1 != $2) and a number of other variations. (Please note that bugzilla mis-reconizes the links here. Our `mozTXTtoHTMLConverter.scanHTML()` does this better.) You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is not fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. Which code is inserting the links here in this case during HTML email composition, if the user does not explicitly mark the URL as link? Is `scanHTML()` being used? If not, why not? That's the bug here.
> Can we define the expected output of <a href="$1">$2</a> in a text/plain part first? That's not the bug here. It's not as simple as that. We also have: * www.foobar.com -> <a href="http://www.foobar.com">www.foobar.com</a> ($1 != $2) * you@example.com -> <a href="mailto://you@example.com">you@example.com</a> ($1 != $2) * <http://www.foobar.com> -> <a href="http://www.foobar.com">>http://www.foobar.com></a> (RFC 2396 appendix E) ($1 != $2) and a number of other variations. (Please note that bugzilla mis-recognizes the links here. Our `mozTXTtoHTMLConverter.scanHTML()` does this better.) You cannot just check URL == link text. That will not work. Please see my comment 5. Even if you fix URL == link text, the bug here is not fixed. The link recognition (plain URL -> link) and the HTML->TXT conversion must be round trips. We achieve that with the HTML classes. The bug here is that the class is missing. Which code is inserting the links here in this case during HTML email composition, if the user does not explicitly mark the URL as link? Is `scanHTML()` being used? If not, why not? That's the bug here.