18249 - Plain text Reply dropping Line Ends for quoted text

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[marina]

Steps to reproduce:
-compose a message in Plain text format;
-get it and click reply;
-reply to the message// the quoting structure looks OK so far;
-send the reply and get it;
//now note that everything looks like a big message body,all in one line
iqatest1 wrote:...........................(reply text)...
(you'll have the same problem when you'll receive in 4.7)

Comment 1

[laurel]

Dup of bug #17983 ?

Comment 2

[Phil Peterson]

Reassign to rhp

Comment 3

[marina]

As far as i understand the # 17983 problem : it is a viewing problem before
send. There is some body loss and no quoting appears as a structure when
composing a Reply. In my case i see the Reply/Quoting structure while composing
but it gets lost upon Send/Receive

Comment 4

[rhp (gone)]

Will investigate.

Comment 5

[rhp (gone)]

Hi Akkana,
This may be a known issue or something fixed, but if I send myself a plain text
message with lots of line breaks, it looks fine when I receive it. Then when I
hit reply, the quoted text still looks fine, but when I send that, all the line
endings for the quoted text seem to dissappear.

Any ideas? Just reassign to me if you think this is a messenger problem.

Also, changing the description here for clarity.

- rhp

Comment 6

[ji]

Same problem on Linux

Comment 7

[Daniel Bratell]

The bug is found and fixed. It was an assumption that every found whitespace was
a space that was wrong.
Akkana has got the fix and will check it in.

Comment 8

[Akkana Peck]

Daniel's fix has been checked in.

Comment 9

[fenella]

Linux Redhat 6.0 (1999-11-12-18 M11) Commercial
Win_nt 4.0 (1999-11-12-18 M11) Commercial
Mac (1999-11-11-11 M11) Commercial
Reply plain text looks fine now.

Comment 10

[Katsuhiko Momoi]

With 11/12/99 Win32 M11 build, line ends seem to be in
reply msgs but there seems to be one remaining problem:

"Amy Jones wrotes: this is a test message."

It seems that the "... wrote"" and the first line of the quoted
text is fused together. Are others seeing this problem?

Comment 11

[marina]

Kat, i don't see this occuring on my machine with 1999-11-10-16 win build.
it looks like iqatest1 wrote:
..........

Comment 12

[marina]

I have to comment this bug again, it looks like the behaviour is inconsistent,
because now i see what Kat was seeing on his machine: all lines are fused in
one.Guess it is too early to verify.

Comment 13

[marina]

With the final candidate build 1999-11-10-16 the problem persisits: i'm seeing
the reply fused with the text all in one line upon receive (the structure before
sending is correct). Reopening.

Comment 14

[Daniel Bratell]

This was fixed in M12 as soon as it opened. The responsible file is
nsHTMLToTXTSinkStream.cpp in /mozilla/htmlparser/src/
To get this in M11 it's just to take that file and copy it to M11.

Comment 15

[Akkana Peck]

Can momoi, marina and fenella please clarify this to make sure I'm
understanding:
It sounds like the problem is fixed in M12 builds, but still exists in M11
builds?
This bug is marked M12, so I don't think M11 is an issue here, unless someone
wants to make a case that the fixes should be checked in to the M11 tree and
tested there.

Comment 16

[marina]

My comments go to M11 build, so it is the source of confusion. I'll check M12
tomorrow, still working on M11 final candidate. Somehow was sure we want it
fixed for M11. Kat?

Comment 17

[Akkana Peck]

Okay, I'm marking this fixed again, since it's fixed for M12.  If someone wants
to argue for stopping the M11 process for this, we can reopen it then if
necessary.

Comment 18

[msanz]

This shouldn't be an M11 stopper. Lisa, do you agree?

Comment 19

[Katsuhiko Momoi]

akkana, the source of confusion is the fact that in M11, it looks almost fixed except for
one problem. But the TM is clearly marked M12. As long as there is assurance that the fix went
into only M12, it's OK with me.

Comment 20

[fenella]

Linux Redhat 6.0 (1999-11-17-09 M12)
Win_nt 4.0 (1999-11-16-09 M12)
I tried the scenario as described in the original report. The reply text looks
fine.