I'll attach some of my testcases for the mozTXTToHTMLConv class here, so other developers / QA can test it to avoid regressions. This bug may also track bugs in / for that class.
Created attachment 62739 [details] Testcases: converter Both this attachment and the next one are "mbox" mailboxes. Mozilla can load them natively as folders, if you place them in the right dir. Same with the UW-IMAP server. This is my complete testcase folder for that converter class. It contains a set of messages with a wild collection of testcases. Some of the stuff there is supposed to work, some is supposed not to work, some happenes not to work. Unfortunately, there is no hint at which is which, so please just compare the results of a build with your changes with the results of a build which is known to work. Make sure that both are identical unless the old one is *obviously* wrong (e.g. <mailto:&$&%> being linked). Please compare carefully: E.g. - in <http://www.mozilla.org>, the brackets are part of the link (but they are not in <www.mozilla.org>) - "hello :-), how are you?" should trigger a graphical smily, while "hello :-),how are you?" and "hello :-)| how are you?" should not.- make sure that the converter doesn't "eat" any chars, i.e. that the comma in the example above is retained. BTW: The "(no subject)" smilies don't work, because some of the whitespace are not spaces (char 32), IIRC.
Created attachment 62740 [details] Testcases: I18N I just saw that you can view the mboxes right in the browser by clicking on the attachment. I don't think that's garanteed to work correctly, though. But nice for a quick check... These are some I18N testcases which I got from Rich, who got it from the i18n group. I added a few of my own ones. There are /no/ special (I18N) testcases for the recognition features of the converter. I attach it here, so you can test the i18n-safetiness of the converter - all the text passes through it, it is potentioanlly modified and should detect URLs moderately well even in non-latin text (but using the lating rules, e.g. spaces around them).
> I just saw that you can view the mboxes right in the browser by clicking on the > attachment. I don't think that's garanteed to work correctly, though. In fact, this method breaks for the I18N testcases, because it is regarded as one message and thus the charset is not sat correctly.
Afte thrashing around for a while trying to figure out if I've broken anything, I've found out that converting html to plain text is broken in mozilla, and has nothing to do with my changes. If you use the html compose window to make some text bold, and send it as plain text, it can get sent incorrectly, or displayed incorrectly (not sure which - if you make " test " bold, it will get sent and displayed as "* test *", which is broken. Perhaps the struct code doesn't handle this case correctly, because of the leading and trailing spaces. Is there a bug on this? If that's the bug, it seems like this code is pretty seriously flawed.