Using 3/16 build from the beta1 branch on Windows NT 1. Read the message I'm about to attach in mozilla 2. Click the Reply button Expected: orignal message to be quoted in reply, with linebreaks preserved Actual: all text from each paragraph is on its own line. All linebreaks within the paragraphs have been removed and the text is not wrapping.

Isn't this a strange message? All the equal-signs at the end of the lines confuses me at least. I thought quoted-printable is that certain characters are replaced by an equalsign followed by a Hex code, but here we have an equalsign followed by non-alphadigit chars, more exactly a line break. Could it be the quoted-printable -> text converter that strips the line endings.

In Q-P, a = at the end of the line means a soft line break. So the Q-P -> Text converter does the right thing, but somehow the compose window should end up with a decently wrapped paragraph.

Hi Akkana, I have a question for the editor guru. I will attach some HTML to this bug that if I load it into the editor, it loads fine and wraps correctly, but if I insert it with the InsertAsQuotation() method...I get no wrapping. Any ideas. - rhp

You're calling InsertAsQuotation in an html editor (i.e. you're really calling InsertAsCitedQuotation with an html argument), or into a plaintext editor (i.e. InsertAsPlaintextQuotation)? If you turn the debug menu back on in the compose window (J-F, any chance we could have that back now that we're back in development mode and not beta branch mode?), you'll get a debug menu that lets you dump the html of the message, or the raw content tree if you don't trust the html. That will give you a lot more information about what the editor is inserting and why it doesn't appear as wrapped.

The debug menu is already back on the tip.

I'm calling InsertAsQuotation into an HTML editor with the attached HTML. I think the problem is that the WRAP tag on the <PRE> for this HTML is not being honored. - rhp

It would presumably be useful to know what ended up wrapped around the pre (e.g. is it inside a blockquote, or is another pre without a wrap attribute somehow getting involved?) That's why I suggested using the debug menu to dump the content tree to see what's there.

Fixed this one. - rhp

Geeze...bugzilla problem again...really, this is fixed!

It looks to me, as if this bug reappeared. REOPENing. Nightly build 2000-05-13 Linux. Debug->OutputHTML shows <blockquote type="cite" cite="s8d0bffc.033@war.wyeth.com"> <pre wrap>Phil, Paragraphs without linebreaks, but ~500 chars. [sig bug] </pre></blockquote> Debug->OutputText as well as SendAsPlaintext produce > > Phil, > > Paragraphs without linebreaks, but ~500 chars. > >[sig bug] > Can somebody else reproduce this? Akk, any hints? Dependency on bug 31906, so that bugfixes don't conflict.

Even if we fix nsHTMLtoTXTConv, I don't think, we will get away with a <pre wrap>. We send this out as HTML. The wrap attribute is a nonstandard HTML extension - you can't trust on support on the recieving side (not sure, if MSIE supports it). If there is no such support, the recipient will see a very long line. Bad. Unfortunately, I have no good solution. The right way to fix this would be to use no pre at all for flowed paragraphs (which makes sense). There are two problems, though: - Not sure how to get this info in mimetpla.cpp. I could check |strlen(line) > 80|, but that's a bit of a hack. - There is no way to distinguish between a flowed paragraphs with < 76 chars and a fixed line. I.e. all paragraphs < 76 chars have to be wrapped in pre (they could be fixed, i.e. contain important leading spaces). So, some paragraphs would be rendered in a fixed width font and others in a variable width font :-(. Any ideas?

hm, maybe use <tt> for flowed paragraphs instead of pre wrap. That way, all text would be rendered with a fixed width font.

Changing qa assign to pmock@netscape.com

I think this has been fixed by the open source fairies :-) - rhp

Re-open bug. This bug is reproducible on current mtrunk builds of win32, linux, and macos. To reproduce bug, reply to test message using plain text compose window. Build used to reproduce problem: win32 commercial seamonkey build 2000-122708-mtrunk installed on P500 Win98 linux commercial seamonkey build 2000-122708-mtrunk installed on P200 RedHat 6.2 macos commercial seamonkey build 2000-122708-mtrunk installed on G3/400 OS 9.04

reassigning to ducarroz

I think this is the bug I encountered today, build 20020311 on W2K. I don't have Quoted-Printable turned on in Preferences. I don't have automatic quoting turned on for reply emails. I looks like I'm using plaint text, not HTML for composition. When I "paste as quotation" the quoted lines don't wrap. This is a big step back from Netscape 4.x (FWIW, someone mentioned that Gravity newsreader has this problem.)

Let me see if I understand this bug. The test message is in QP and has all the paragraphs in one line each (that's what the = at the end of the line means). Those lines are not wrapped when quoting. Well, this is correct. Mozilla does not and should not wrap lines when quoting. A similar bug ist bug 124175 (same "problem" with paste as quotation). I believe, this here is the same as bug 110754. IOW: I think this is INVALID. pi

Boris, you misunderstood it. The message contains abc[...]def= abc[...]def= abc[...]d abc[...]def= abc[...]def= abc[...]d (each line bein 70-80 chars long), and we "unwrap" that to abc[...]def abc[...]def abc[...]d abc[...]def abc[...]def abc[...]d (each line now being way longer than 80 chars, because the contain the whole paragraph), and we actually it send that way, i.e. with lines of about n*80 chars. This is a bug, which makes reading the quote in many MUAs very hard.

*** Bug 110754 has been marked as a duplicate of this bug. ***

To be utterly clear: libmime does the right thing here by unwrapping the paragraph.* That's what the author ('s MUA) intended by sending these QP-flowed lines in the first place. The bug is when we go and send the whole paragraph on a single line. We should instead rewrap it as we see fit (that's the point of soft linewraps) in the composer or during sending. *(At most, libmime uses the wrong HTML tags for Gecko.)

Is this in the normal editor or in the plain text editor? If it's in the plain text editor I guess we just don't wrap the text before quoting it with ">".

Ben, I do not agree. As you say, it is correct to unwrap it. But there is no way (below artificial intelligence;-) to decide, if the long lines are intended by the sender of the previous message. Let me give an example. I have some text containing a pseudo-table (kind of ASCII art). This forces my line length to 100 say. No I use QP. This forced the lines to be folded using = no later than after 76 encoded characters (RfC 2045). If we now decide to use these soft line breaks to interpret paragraphs and re-wrap that text, we end up with a seesaw quoting. OTOH I understand your intention looking at the test messages. In this case it *happens* to be the case that paragraphs are completly wrapped using soft line breaks, but this is not the case with many typical implementations of QP, like in Forte Agent or Mozilla. The following example was written in Mozilla: This line cont=E4ins m=E4ny =FCml=E4uts. And it is l=F6ng, really l=F6ng = that is to see the effect of hard and, =E4h, soft line breaks mixed in quoted-printable. As you can see, there hard *and* soft lines breaks in one paragraph. Mozilla can't know, if this is one paragraph or three. Daniel, this is happening in the plain text editor, I cannot say if it also happens in the HTML editor. pi

(BTW: The reference is RFC 2045, Section 6.7, Items 4 and 5. It says "soft line wrap", which in my understadning means that I can remove the soft line wraps and rewrap it however I please. > But there is no way (below artificial intelligence;-) to decide, if the long lines are intended > by the sender of the previous message. Of course there is. That's what the "="s at the end of the lines are for. > I have some text containing a pseudo-table (kind of > ASCII art). This forces my line length to 100 say. No I use QP. This forced the > lines to be folded using = no later than after 76 encoded characters (RfC 2045). You cannot reliably have tables wider than 80 chars in plaintext. With my suggestion, you'd end up with a quote that looks exactly the same (minus "=") as if you'd view the table in a non-QP-linewrap-supporting MUA, of which there are plenty, I'd guess. > In this case it *happens* to be the case that paragraphs are completly wrapped using soft line > breaks, but this is not the case with many typical implementations of QP, like > in Forte Agent or Mozilla. I do think that the problem msg her is the common case. 4.x Mac produced that. > The following example was written in Mozilla: > This line cont=E4ins m=E4ny =FCml=E4uts. And it is l=F6ng, really l=F6ng = > that is > to see the effect of hard and, =E4h, soft line breaks mixed in > quoted-printable. Is that in a format=flowed or unflowed mail (see MIMEtype)? I'd argue that this is a Mozilla bug. Even if strictly valid, this just makes no sense (esp. considering that we support flowed).

Let me first of all again mention bug 124175 where Akkana basically comes to the same conclusion, see: http://bugzilla.mozilla.org/show_bug.cgi?id=124175#c7 and http://bugzilla.mozilla.org/show_bug.cgi?id=124175#c10 > (BTW: The reference is RFC 2045, Section 6.7, Items 4 and 5. It says > "soft line wrap", which in my understadning means that I can remove > the soft line wraps and rewrap it however I please. That might have been the idea at some point. But that is not what is actually used as my example shows. >> But there is no way (below artificial intelligence;-) to decide, if >> the long lines are intended by the sender of the previous message. > > Of course there is. That's what the "="s at the end of the lines are for. No, they must appear for lines with encoded (!) more than 76 characters. A following hard line break can mean either the actual end of a paragraph or just a line ending. You want to assume that always the first case appears. > You cannot reliably have tables wider than 80 chars in plaintext. That doesn't mean it is not used, in which case Mozilla must be able to handle it in a way which does not render it completely unreadable (as Outlook Express does for example). And even for 80 (probably 79) characters you would end up in rewrapping since you add additional two characters to mark the quoting. And again you have a problem. > With my suggestion, you'd end up with a quote that looks exactly the > same (minus "=") as if you'd view the table in a > non-QP-linewrap-supporting MUA, of which there are plenty, I'd guess. I use quoted-printable since around 1995. And actually only very few UAs cannot handle it. Those certainly exist (like Free Agent), but they are in trouble anyways. It is my strong opinion that Mozilla should be better. And it actually is right now -- handling messages correctly when quoting. >> The following example was written in Mozilla: >> This line cont=E4ins m=E4ny =FCml=E4uts. And it is l=F6ng, really l=F6ng = >> that is >> to see the effect of hard and, =E4h, soft line breaks mixed in >> quoted-printable. > > Is that in a format=flowed or unflowed mail (see MIMEtype)? Unflowed. > I'd argue that this is a Mozilla bug. Even if strictly valid, this > just makes no sense (esp. considering that we support flowed). No, it is absolutely correct. I want to achieve the following: My text shall be wrapped to 70 characters (no optional rewrapping). Also I want to be RfC 1036 compliant, i.e., I must restrict the message to ASCII which could be achived by quoted-printable or base64. The former seems to be the better choice. Now there is no other way to achieve that than in the above example. BTAIM, this is what programs do, so Mozilla must handle this. Conclusion: A "fix" will produce seesaw quotings similar to Outlook Express. It relies on assumptions which do not agree with real postings (or mails). You can only break things here. If you want to rewrap, you can always go and use that function. pi

> And it actually is right now -- handling messages correctly when quoting. As this bug shows, it is not handling it correctly. The case mentioned here is all-messed-up, and it's not the fault of the original sender, but Mozilla. We must not send lines longer than 80 chars. The Rewrap function of the Composer is no solution, because it won't be used by the majority of users. [Mozilla] > Unflowed. Which makes it practically insignificant, because that's not the default and there's no UI to turn it on. > Now there is no other way to achieve that than in the above example. You could just break the line earlier, completely avoiding the softwrap. I.e. use the 76-char-wrap *after* QP encoding, not before.

> The case mentioned here is all-messed-up, What do you mean by messed up? There are long lines. But the text is completely readable. > We must not send lines longer than 80 chars. I see, you want to destroy URLs which makes them unusable. And in effect you destroy anything intended longer for good purpose like ASCII art, pseudo tables, program listings. > The Rewrap function of the Composer is no solution, because it won't > be used by the majority of users. The majority used OE which produces unreadable quotes. I don't agree this is the way to go. > [Mozilla] >> Unflowed. > > Which makes it practically insignificant, because that's not the > default and there's no UI to turn it on. So what? The same way other readers code messages. It is completly correct and wide spread. >> Now there is no other way to achieve that than in the above example. > > You could just break the line earlier, completely avoiding the > softwrap. I.e. use the 76-char-wrap *after* QP encoding, not before. That is the way it happens. First you write the text. Then hard line breaks are inserted after 70 characters or earlier, then QP is applied to characters outside ASCII (and a few more). Finally the 76-char-rule has to be used. To avoid that you have to go way below 70 characters which depends on the number of characters to be encoded. For UTF-8 this can easily code on character to nine, just a few get you beyond 76. pi

On more remark on "must not send lines longer than 80 chars": This also means that you must rewrap quoted lines which would mean you had to apply the rewrap routine automatically. This is extremely dangerous and would destroy all structure in plain text messaging as found in Usenet. pi

> There are long lines. But the text is completely readable. No; as I said, in many mailers, lines longer than 80 are *not* readable. And esp. lines a few 100 chars long. That's the reason why all the mailers wrap at 76 chars. > I see, you want to destroy URLs which makes them unusable. [...] OK, there are exceptions. Normal English text (as in the problem msg) is certainly none, though.

(missed that comment) > On more remark on "must not send lines longer than 80 chars" OK, yes, that statement was too extreme, I didn't think. Still, producing quoted lines that are in the msg source a few 100 chars long, when they weren't in the original msg, is a no-go.

>> There are long lines. But the text is completely readable. > > No; as I said, in many mailers, lines longer than 80 are *not* readable. I don't know a single reader which would not be able to break lines wider than the screen itself. Even my very first newsreader (nnr on an IBM mainframe) did that. Of course, this does not result in optimal readability, shorter lines are better to read (actually on should go for 60). But that is something the user agent might want to do with long lines when displaying. But there is a choice here. One which only a human can make, no machine can really know if it is important that the line has a given length for whatever reason. As you agreed in your last comment, those examples exist and must be taken into account. Any fixed limit does not do it. Make the rewrap function more visible and people will use it as required. pi

The original message does have lines that are 100s of characters long. Each paragraph in the message attached to this bug is on a single line. That is explicitly what the composer of that message generated. People are confusing content with encoding. Quoted-printable is a MIME Content-Transfer-Encoding and as such serves the purpose of taking content that does not fit the contstraints of a transfer channel and reversably encoding it into a form that does. Just as is the case with base64, the form of the content-transfer-encoding has no bearing whatsoever on how the receiver interprets the content. If you want a mechanism for specifying how the content should be wrapped for display, then format=flowed (RFC 2646) would be an appropriate mechanism.

I filed bug 144842 to track the issue of wrapping quoted text at a slightly wider point than original text, since that's a different issue which keeps getting mentioned but doesn't have an explicit bug to track it.

> People are confusing content with encoding. No, I'm not. For mailers which don't understand QP, the lines have the right length. Mailers which do understand QP are supposed to wrap as needed. You don't want to tell me that the sender intended these lines to be hundreds of characters long, one line per paragraph, do you?

There is no requirement in MIME for readers to wrap the lines after decoding the QP. Please support your contrary claim that mailers which do understand QP are supposed to wrap as needed with a reference to the place where such requirement is stated in the standards. I am telling you that the composing program generated lines that are hundereds of characters long. The sending user's intention may well have been different, but a mismatch between the sending user's intention and the composing program's output is a bug in the composing program, not in Mozilla.

I think there are simply different interpretations of the RFC. 1. "soft line wrap" means exactly what I described - remove the soft line wraps and you get a paragraph, which you can then rewrap as you please. 2. "soft line wrap" means that that you remove the line wraps and get a single line. The author of GroupWise and Netscape Messenger 4.x Mac and I thought that 1. were the right interpretation. John and Boris think that 2. were the right one. Rereading the spec (5) (Soft Line Breaks) The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long. If longer lines are to be encoded with the Quoted-Printable encoding, "soft" line breaks must be used. An equal sign as the last character on a encoded line indicates such a non-significant ("soft") line break in the encoded text. ("If longer *lines*..."), I guess I was wrong. I think that the spec is broken, because a) I associate "soft line breaks" = with paragraphs and automatic wrapping and b) it encourages "embarrassing = line wrap" like in this paragraph, which makes the message very hard to read and = which is a good reason not to use QP soft line breaks at all. So, our current behaviour could be considered strictly correct, although it obviously results in what nobody intended. I.e. that doesn't mean that this bug should not be fixed. We unfortunately have tons of places in libmime (and layout) where we violate the spec in order to work with real world software.

Your interpretation of the parentetical label "(Soft Line Breaks)" is completely unsupported by the text of the RFC. The text following it clearly specifies the semantics of that rule and omits any statement about automatic wrapping upon decoding the transfer-encoding. Your interpretation contradicts the specification of the interpretation and use of content transfer encodings given in section 6.2 of RFC 2045: This single Content-Transfer-Encoding token actually provides two pieces of information. It specifies what sort of encoding transformation the body was subjected to and hence what decoding operation must be used to restore it to its original form, and it specifies what the domain of the result is. The transformation part of any Content-Transfer-Encodings specifies, either explicitly or implicitly, a single, well-defined decoding algorithm, which for any sequence of encoded octets either transforms it to the original sequence of octets which was encoded, or shows that it is illegal as an encoded sequence. Your interpretation also fails to fit the Canonical Encoding Model specified in Section 4 of rfc 2049. Simply put, decoding a content transfer encoding can only produce the octet stream that was the original content. Automatic wrapping upon decoding produces a *different* sequence of octets than which was encoded and thus is outside the scope of what a content transfer encoding is permitted to do. That the MIME spec has no words to support your misinterpretation is not a fault of the MIME specification. That the encoded form of quoted-printable is not as readable as originally intended is generally acknowledged, but that does not detract from the fact that it does reliably serve its primary purpose of encoding arbitrary content for transfer over restricted channels. Rule 5 does serve the purpose of transmitting long content lines over transports with short line length limitations. There is value in implementing bug-compatibility features, generating better results when presented with input generated by buggy programs. Such work should be recognized as being in that class. The problem is not that we are unwrapping quoted-printable paragraphs, the problem is that we want to wrap the extremely long lines generated by buggy sending clients.

> The problem is not that we are unwrapping > quoted-printable paragraphs, the problem > is that we want to wrap the extremely > long lines generated by buggy sending clients. Long lines in an incoming message do not imply "buggy sending clients." I think some of this discussion is missing the point, citing standards and not recognizing the problem. I don't know the 'standards', but I do know that Mozilla's behavior is not the generally accepted behavior, is not acceptable (regardless of the 'standards') and should be changed. (In Netscape 4.x quoting a message gives a single GT symbol (>) at the start of each paragraph, but the lines do wrap when quoted.) Here's my view of the problem: Assuming (correctly, I believe) that receiving clients can wrap long lines to a chosen length or, by default, to whatever width the client screen may be, I have often set my Composer margins very wide, like 2000 characters. I do this because I am often annoyed by quoted messages coming to me with bad line breaks, and it seems a courtesy to readers, who sometimes may quote my messages, to help them avoid the linebreak problem by giving them very long lines to break whereever their programs want to break them. _Until_using_Mozilla_ I have also appreciated receiving email in a long-line format for the same reason. Long lines should be quoted as long lines (in case the line breaks do have contextual meaning), but they have to wrap on the screen of the sending client. (If the long lines have contextual meaning, the recipient has to find a way to display them long.) If recipient has Composer's default setting to quote a message on reply, s/he gets these unreadable lines. Often one wants to quote only a small snipped of of the original message, or wants to break the message at certain points to make targeted comments, and it is very hard to find when there are no line wraps.

*** Bug 149271 has been marked as a duplicate of this bug. ***

*** Bug 192568 has been marked as a duplicate of this bug. ***

May I say it's quite ridicolous that such a bug it's still there after three years? Don't we all live in a world full of people using outlook express?

Andrea, I cannot get your point. Mozilla behaves perfectly regarding QP see, e.g., comment 39. So this should be marked INVALID. Outbreak Excess to the opposite badly fails with regard to QP. pi

The point is simple: the application is meant for the end user, not as a tool for tech evangelism. If the end user cannot get it to work properly he will change mail client, since it's not conceivable that he will be able to make all the people he receives mail from use a standard complaint mail client. A good application is also tolerant to data input which is not standard conformant, but widely diffused.

AWGTHTGTATA? I use QP every day. Mozilla sends and receives it correctly. I observe this for many different senders using different clients. It simply works (as opposed to format=flowed). Any change will severly break Mozilla and make it completely unusable. The result would be things like OE creates them: asjdf fashfl kalsjk dfkas fja ssdfjas fjlas asdfasf asdfas fa jdf askfjkl asdklfjas dfj klas dfjk asdfas as fkkjl asdfj klasdj fklajsf ksad dfj asd Simply horrible. pi

If everything works so fine for you, can you tell me why then same messages sent me by an outlook express user generates the "one big line" problem when replied, and no problem (that is, properly formatted) when forwarded?

Obviously because the message was sent with long lines. And BTW OE limits those to 130 characters which is a serious bug. So what you observe has exactly nothing to do with quoted-printable, but with the display of mails in text/plain. pi

I think the bug is not in Mozilla's processing of QUOTED-PRINTABLE coding, but in processing of long lines when replying. Look at the http://bugzilla.mozilla.org/show_bug.cgi?id=192730, it describes very similar problem which happens with replying to plain-text messages.

Problem still exists as of: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030220 I have noticed in practice, but not on this bug that if I reply as plain-text, I see the problem. If, in Edit->Mail and Newsgroup settings I check send in HTML format, I do not get the problem, but that's not really a good option, sine I prefer to compose in text. I see only mention of OE, but I've also received messages from Eudora and mac.com's webmail that exhibit this problem when replied to. Also, I believe comment 39 is actually *for* changing this behavior: > There is value in implementing bug-compatibility features, generating better > results when presented with input generated by buggy programs. Such work > should be recognized as being in that class. The problem is not that we are > unwrapping quoted-printable paragraphs, the problem is that we want to wrap > the extremely long lines generated by buggy sending clients. as the above statement seems to imply that there is value garnered from working around a buggy sender, if indeed that is the problem. Maybe I'm misquoting John, but that's how I read it.

Just for your notice: if you want to have fun, subscribe to the sapdb.general@listserv.sap.com mailing list and try to reply to a message coming from sap employees... you always get the problem described in this bug. Since I need to work on that list, I'll have to switch to another mail client.. Btw, the X-mailer used for these messages appears to be: X-Mailer: Internet Mail Service which I guess is some kind of Microsoft product (a web mail, whatever...)

If those people send it this way, you can still use the rewrap feature. pi

Doh, I didn't know about this feature! Wonderful, I can keep my Mozilla e-mail client now :-)

Great, can we close this bug now as WONTFIX or INVALID? Comment 39 says it all, Mozilla is correct. If you don't like it, just rewrap and everybody's happy. pi

To be sincere, the rewrap is just a bandaid. The problem is not about correcteness, is about user friendliness. Programs are build to help people do something, not to enforce standards. The client must cope with incorrect but common input, otherwise people will just switch back to OE, as I was tempted to do. Not much people will post a bug and question like me, they will only decide that Mozilla is broken an get back to something which they know works as expected). Please undertand that a mail client it's just a tool for most people, and most people don't know or care about what a RFC or other standard is.

Please *read* this bug! There is no way to determine what is right or meant. Changing the behavior will break things which then cannot be repaired manually. See the trash Microsoft programs create all the time. pi

pi wrote: > can we close this bug now as WONTFIX or INVALID? No. > Comment 39 says it all Compare what Kevin wrote: > Also, I believe comment 39 is actually *for* changing this behavior: [...] > as the above statement seems to imply that there is value garnered from > working around a buggy sender, if indeed that is the problem. Maybe I'm > misquoting John, but that's how I read it. me too.

I have two messages I've received from someone. The original messages (replies to my messages as plain text) had the problem displayed in this bug when I reply. I got fed up, and replied in HTML. the following message worked when replying as plain text. They are both X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 The differences in the headers: Original e-mail w/ bug behavior: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Follow-up e-mail w/o the bug behavior: Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DA8B.45549E3A" Content-Transfer-Encoding: 7bit

This attachment proves that this bug is INVALID. Both mails in this mbox have identical content. They first uses quoted-printable the second 8bit as an encoding. Clearly, Mozilla treats those identical bodies as identical, i.e., displays exactly the same and a reply looks identicall, too. So unlike the summary suggests, this has exactly nothing to do with quoted-printable. Furthermore, the summary is wrong, it should read: "Quoting quoted-printable message does not wraps paragraphs" (which would be an "enhancement" and not a bug). So I suggest to close this bug and file (or better find) a new bug which suggests to break the content in a reply. pi

There is no need to file new bug, there is http://bugzilla.mozilla.org/show_bug.cgi?id=192730, which describes the same problem but with plain text messages. But in the comments to that bug there is a reference to this one. I think only one of them should be considered invalid, and my opinion that it is this bug to be invalid.

I finally found it. This bug here is a special case of bug 20240, so I dupe it there. I also filed bug 196033 which follows the suggested solution to this bug in the general case. pi *** This bug has been marked as a duplicate of 20240 ***

fine, then.

so which bug do you want to keep open? Bugscape # 20240 (that is resolved as invalid) or bugzilla bug?

As I said in comment 61, there is bug 196033 with a "solution" to this "problem". pi