21688 - [Dogfood] Headers are all collapsed into 1 line when forwarding certain types of msgs

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 12/13/99 Win32 build (1999121314) **

In the Intl Somketest file I use, if I forward/inline the 2nd and
3rd messages under HTML send option, all the headers are quoted "fused"
into 1 line. We used to have this problem for almost all msgs but now
only certain types of msgs seem to exhibit this problem.
The 2nd and 3r msgs in the Smoketest file are typical. Other 3
msgs in the Smoketest file do not cause this problem.

Comment 1

[Katsuhiko Momoi]

Attachment: Intl Smoketest File.

Comment 2

[Katsuhiko Momoi]

Please save the attached file as "smoketest.zip" and
un-archive it using the Zip utility.

Comment 3

[Katsuhiko Momoi]

Actually, since the HTML or Plain Text option changes depending on
what the original msg was, this problem happens with both
HTML and Plain text send option.

The 2nd msg in the Smoketest file will induce Plain Text mail
and the 3rd, HTML mail.

Comment 4

[Katsuhiko Momoi]

Originally I set the send option to HTML but the problem happens
when the send option is Plain Text also.

Comment 5

[Katsuhiko Momoi]

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

Comment 6

[Katsuhiko Momoi]

I have been able to narrow this down to the following. It looks like
this will be a serious problem for non-English Plain text mail users.

This problem occurs under the following conditions:

1. When the original mail contains "Plain text body".
2. When the original mail contains non-ASCII characters
   in the headers, e.g. Subject line.

Apparently, as we try to form forwarding headers, line breaks are
lost if the headers contain non-ASCII characters under the above
conditions.
I'm going to raise the severity to critical. I would like to get
this fixed for M12 if at all possible.

Comment 7

[rhp (gone)]

Jeff,
Can you take a look at this?

- rhp

Comment 8

[Katsuhiko Momoi]

In addition to the plain text original, I found one condition under
which the original HTML mail body causes this problem also.

1. Go to some web page with 4.x -- it does not matter which. Netscape
   English Home Page will do for this purpose.
2. Send this page to your Mozilla mail account but make sure that
    a. Your digital sigature is attached.
    b. Your vCard option is turned off.
    c. Include some Latin 1 "accented" characters in your Subject.
4. Receive this msg with Mozilla. Now try forward as inline on
   this message. You will see that header lines lose the line breaks.

I found that:

When the message is an HTML type with simple multipart/mixed parts,
e.g. a web page attached to your message (containing non-ASCII headers),
this problem does not occur on forward/inline.

But if you add your siganture to this, you get:

multipart/signed; protocol="application/x-pkcs7-signature"

wrapping up the multipart/mixed part. Under this condition,
the problem occurs.

Another way to induce this problem easily is to have
both vCard and digital sigature turned on. This will
produce the same structure as above.

1. Try a message which contains non-ASCII headers, HTML body,
   vCard (non-ASCII OK),and a digital signature. The problem will be
   visisble if you try Forward/inline on this message.
2. Now skip the signature to the same message as in
   step 1. In this case, the problem will not occur when you
   engage Forward as inline on it.

Comment 9

[jefft]

Sure...

Comment 10

[leger]

Is there a clear dogfood workaround here?

Comment 11

[Katsuhiko Momoi]

I just filed a related bug -- Bug 21856.

Comment 12

[bobj]

The workaround is to forward as attachment and do NOT forward as inline.
This can be marked PDT-.

But it is definitely needed for Beta (hopefully by M13).  Feedback is that in
Japan most users use forward as inline as opposed to forward as attachment.

Comment 13

[bobj]

This bug should be reduced to the forward as inline of PLAIN TEXT email.
(The HTML case has been logged as a separate bug 21856.  See comment above.)

In the plain text case, if you look at the HTML generated for the message
compose window, the linebreaks are missing.

Comment 14

[Katsuhiko Momoi]

I think we should keep the HTML case also where it loses linebreaks.
Bug 21856 was filed for another bug, that of losing the
body and the attachment under the same condition which causes this
bug.

Comment 15

[leger]

Putting on PDT- radar...you can fwd as attachment :-)

Comment 16

[jefft]

Move to M13....

Comment 17

[jefft]

This is fixed along with fixing bug 21869.

Comment 18

[Katsuhiko Momoi]

** Checked with 12/24/99 Win32 Mozilla M13 build **

The 2 types of problems as I described above dont appear
to be fixed in this new build.
Also note that the plain text example I mentioned first
does not contain any multi-parts to begin. It is just a single
body 1-line message with nothing else.
Re-opening ...

Comment 19

[jefft]

We are having problem with the second message of the Smoketest folder. We
stripped out all the CRLF when doing MIME_DecodeMimePartIIStr(). I wonder why?

Comment 20

[jefft]

Fix checked in to conditionally strip out the line continuation.

Comment 21

[Katsuhiko Momoi]

Esther, if you don't mind, let me check on this fix. Assigning myself as
QA contact.

Comment 22

[Katsuhiko Momoi]

** Chcecked with 1/24/00 Win32 build **

I tried all the original scenarios mentioned above
with msgs which contain non-ASCII in headers. 1) 2 msgs in
Smoketest file, 2) HTML mail with S/MIME and/or vCard.

In none of these cases, line-collapsing occurred.
Marking fix verified/fixed.