Hi all,
If you're interested, please take a look at
https://bugzilla.mozilla.org/show_bug.cgi?id=1146099#c22.
Thunderbird uses two MIME decoders, the jsmime one and the M-C::Network one.
The jsmime one is used here:
https://dxr.mozilla.org/comm-central/search?q=mimeConverter-%3EDecodeMimeHeader&redirect=false
(five times).
The M-C:Network one is used here:
https://dxr.mozilla.org/comm-central/search?q=DecodeRFC2047Header&redirect=false
(once).
That means that the entire system has been changed over to jsmime, minus
the one call site in
mailnews/mime/src/comi18n.cpp
The two decoders give different results in some cases and therefore
cause inconsistencies in the UI. Specifically, the jsmime decoder works
better, that means, it is more error tolerant to malformed headers.
That's what this bug 1146099 is about.
I don't know why the last call site wasn't changed over, maybe is was
left out deliberately. The only reason I could think of would be a
threading issue. Apparently XPCOM written in JavaScript must run on
Gecko's main thread; that was the issue why Outlook import doesn't work
any more since jsmime was introduced.
Simply switching decoders in comi18n.cpp gives the desired result in
manual testing and Mozmill tests but causes massive Xpcshell test failures.
Any insight, especially from Joshua, would be most welcome.
Jörg.