Closed Bug 142225 Opened 22 years ago Closed 22 years ago

Rewrap changes characters

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jf, Assigned: bugzilla)

References

Details

(Keywords: dataloss, regression) 

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: FreeBSD → 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?
Keywords: dataloss, regression
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
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.