Rewrap changes characters

RESOLVED WORKSFORME

Status

MailNews Core
Composition
RESOLVED WORKSFORME
16 years ago
10 years ago

People

(Reporter: Jens Fallesen, Assigned: Jean-Francois Ducarroz)

Tracking

({dataloss, regression})

Trunk
x86
All
dataloss, regression

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
Seeing this on trunk build 2002050208 on win98.

It's annoying! ;-(

Comment 2

16 years ago
I have it too since 3 days :-/

Build 2002050408 - WinXP.

Changing OS to All.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: FreeBSD → All

Comment 3

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

Comment 4

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

Comment 5

16 years ago
I hope this is trunk only bug or am I wrong?
Keywords: dataloss, regression
(Reporter)

Comment 6

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

Comment 7

16 years ago
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.

Comment 8

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

Comment 9

16 years ago
I am no longer seeing the problem. Shouldn't this bug be marked FIXED?
(Reporter)

Comment 10

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

Comment 11

16 years ago
Per report and user comment: WFM
Status: NEW → RESOLVED
Last Resolved: 16 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.