Comment 140 for bug 369150

(In reply to comment #132)

> (2×) The "old" code used to have fallback
> e.g. decodedName.length() ? decodedName.get() : pNames
OK, should be easy to fix.

> (6×) These should be converted to the form
> CopyUTF8toUTF16(outCString, recipient);
OK, should be easy to fix.

> It's confusing that some fields are decoded here and some are decoded
> elsewhere... is it possible to decode them all in the same place?

I agree, but I wanted to change as little as possible to fix the problem encountered. IMO all else would have strongly increased the probability of regressions. Strictly thought-through, all MIME encode/decode operations should be done in one single place. As noted in comment #99, I neeeded to change different code for the message list, message display, "reply", and "edit as new" operations. IMO, MIME-decoded header data should never be used internally, only for displaying the data to the user (immediately before putting the text in some GUI field). But that would go far beyond the bug fix that I attempted here, and had better be done by someone with a deeper understanding of the data flow between different mozilla components than me. For example, some Mozilla components may rely on parsing some header data in clear text and would fail with MIME-encoded data (I don't know if that's the case, I just wanted to minimize the risk to encounter that situation).

> What does MimeHeaders_convert_header_value do that we don't want it to?

See comment #99. MimeHeaders_convert_header_value() converts MIME encoded data to clear text. If the MIME encoded data contains a comma, later parsing will falsely split the header into fields. This is exactly what this patch is all about.