For the past few days, the CVS builds have been showing problems when using the rewrap function when replying to messages. After running a rewrap, the first character of each original line (which may now well be in the middle of a line) is changed to the null character. Note that it is the first character of the actual message, any number of > characters and spaces before the first character are untouched. This can be reproduced all the time. It does not matter whether the mail I am replying to is HTML or plain text. I have setup Mozilla to reply to all mail as plain text so even HTML mails are replied to in plain text. Tested on FreeBSD with a build based on a CVS pull as of 08:00 UTC on 4 May 2002 , even though the problem has been there for a few days. I am not quite sure why my Mozilla puts 20020411 as the date stamp.

Seeing this on trunk build 2002050208 on win98. It's annoying! ;-(

I have it too since 3 days :-/ Build 2002050408 - WinXP. Changing OS to All.

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

And what is more, the message is lost (emptied) after that character.

I hope this is trunk only bug or am I wrong?

Apart from the characters being replaced with NULs, I am not seeing any lost data and never was. Just tested on 2002051107 (FreeBSD).

2002050208 How I discowered it? My friend asked me why I sent him a letter with only 'Hello' in the body. Later I've tried to investigate the problem and found a trick how to check. While composing reply make Options->Rewrap. If null-character appeared, save message by Ctrl-S and go to 'Drafts' folder. You'll see that composed message is truncated just after first occurence of null. And, sure, the message is sent in that form, i.e. trunkated... As for me described behavior (character replacement) appears not with every message, but I did not discover any systematiс order.

In my case, with build 2002051908 the null characters are not inserted anymore.

I am no longer seeing the problem. Shouldn't this bug be marked FIXED?

I (reporter) also no longer see this problem with 2002100310 build. In fact, I have not seen it for quite a long time…

Per report and user comment: WFM