Win32 build 2000121520 (Win98SE) I just replaced my pretty stable 11-30 build and have noticed a quirk responding to non-flowed plain text mail. There is an extra an extra ">" line between each quoted line in the compose window. Like blah wrote: > > >> blah blah > >> blah blah > which should be blah wrote: > >> blah blah >> blah blah The extra line is always there, regardless of the actual line length. This doesn't happen responding to format=flowed plain text, or to html mail - quoted text is formatted as expected in these cases. The extra lines don't appear in the view window, just the compose window. I have format=flowed turned off in my prefs, plus every html mail option possible turned off.

This still occurs on build 2000122320. IMHO, this is a serious useability issue. The added blank lines in quoted text are compounded with each subsequent reply. There is a thread in netscape.public.mozilla.mail-news that shows the effects - "increasing slowness" started 12/20 by Ian Tindale. A post by hkrause and the replies show what is happening. Or go to n.p.m.general, find any post by Gervase Markham (who always posts with NS 4.x), and hit the Reply button. Assuming automatic quoting is turned on in prefs, there will be a blank line between each line of Gerv's message in the compose window. Can somebody please at least confirm this bug?? Pretty please? I know I'm not the only one to see this.

Verified. Thats really nasty. To Reproduce: 1) Create Email to oneself 2) Insert random characters 3) Send Email 4) Reply to email to oneself 5) Add text between > 6) Watch #'s of > Increase Linearly Platform: PC OS: Linux 2.2.16 Mozilla Build: 2000122808 M18 Trunk Build Marking NEW.

bug 63555 might be a dup, technically.

Yes, this and the other bug seem to be the same thing. It really doesn't matter whether a message contains quoted lines (> ....) or no quoted lines. All non-flowed plain text msgs display with extraneous linebreaks. But the other bug is assigned to the right group, I think.

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

I can absolutely confirm this behaviour, it's really annoying.

Well, even if you select some non-flowed text in the message display window and then 'paste as quotation' then also the blank lines with > appears.

ccing a few people for the HTML->TXT converter, for the case they have an idea. ccing vidor, because he touched lines with '\n' etc. int that timeframe, although the change <http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/base/src&command=DIFF_FRAMESET&file=nsPlainTextSerializer.cpp&rev1=1.9&rev2=1.10&root=/cvsroot> looks harmless.

As noted in bug 63555, win32 build 121204 is the last build that doesn't have this problem. build 121404 and everything since do. builds 121220 and 1213 may, but xpcom.dll crashes every time I start mail in these builds, so I can't confirm.

This is a parser problem. Suddenly the parser are letting CRLF through as CRLF. It used to replace CRLF with just LF and there is a lot of code written under that assumption so the CR adds an extra newline. I've patched my nsPlaintextSerializer to cope with CRLF and that removes this problem but not the display problem amongst others so I rather see the parser fixed. This was probably a regression from the big SlidingSubstring landing so I cc harishd, heikki and jst who reviewed it. I'm also changing component to the parser.

And change component for real.

Vidur, this one is for u ;-)

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

'intl' and 'nsbeta1'

i wonder if the checkin for bug 62031 has anything to do with this

nsPlainTextSerializer is also a content sink. Working on a patch for it as well.

This bug should be on the IQA radar.

Please also check bug 63555's repro. (Also remmember it during verification.)

Attached a new patch that should also fix the plain text serializer. Anyone want to confirm that this patch works? Adding scc@mozilla.org to review template code added to nsLayoutUtils.cpp. Johnny, could you review the rest?

Sure, the patch does (as we've alrady discussed) add a string copy to the plaintext serializer if it's used through its nsIContentSink API but that API shouldn't be used anyway so it's acceptable. The whole patch looks good to me, r=jst

Sorry for dragging my feet on this one. I posted a new patch that fixes a gcc compiler error with some of the template code (bad compiler!). I'm still afraid that I'm going to break some outlying platforms with the template shenanigans, but I aim to get this in today.

This was checked in yesterday...mark fixed?

Same problem appears when replying to HTML message with 2001012404/Win2k. Is this an another bug?

Looks fixed to me. Tried build 012304 out with html, plain text, format=flowed, non-flowed, western and japanese charsets and couldn't make it break. Yee ha! Can't confirm any continuing problem noted by KOIKE Kazuhiko above, though, since I have neither W2K nor any flavor of Outlook.

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

Can we mark this bug fixed so that we can test the fix that had been checked in?

Yes, this is probably fixed. Marking as such to make QA happy :). Reopen as necessary.

.

I filed bug 68087 for HTML mail.

That bugzilla bug again...

.

updated qa contact.

Verified on: build: 2001-03-28-04-Mtrunk platform: WinNT While replying to an e-mail, '|' sign appears instead of >.

Verified on: build: 2001-03-28-04-Mtrunk platform: WinNT Extra > are not added. As '|' is displayed instead of '>'.

ack! This bug is back with win32 build 2001041004. I saw in Bonsai that many changes were checked in on 4/9 related to text/string/whitespace handling. Is one of these the culprit?

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