Closed Bug 116842 Opened 19 years ago Closed 5 years ago

mozTXTToHTMLConv: Tracking and testcases


(Core :: Networking, defect)

Not set





(Reporter: BenB, Unassigned)


(Depends on 5 open bugs)


(Keywords: meta)


(2 files)

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.
Attached file 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 <>, the brackets are part of the link (but they
  are not in <>)
- "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.
Attached file 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.
Depends on: 115160
Keywords: meta
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.
Filed bug 117009.
Depends on: 117009
Depends on: 106028
Depends on: 128138
Depends on: 68044
No longer depends on: 68044
Depends on: 147458
Depends on: 20212, 23327, 39058, 76732, 126701
Depends on: 140928
Depends on: 437495
QA Contact: benc → networking
Depends on: 540606
Depends on: 548982
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.