Closed
Bug 63555
Opened 25 years ago
Closed 25 years ago
Plain text: Linebreaks are doubled in mail view
Categories
(Core :: Layout, defect, P2)
Tracking
()
mozilla0.8
People
(Reporter: kazhik, Assigned: bugzilla)
Details
(Keywords: intl, regression, Whiteboard: [nsbeta1+])
Attachments
(4 files)
Linebreaks are doubled in message view.
It seems a line break is added to the end of each line.
[Edit Message As New] opens the message correctly, but
[Reply] quotes the message as it is seen in message view.
This problem happens with Japanese messages.
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=551
Reporter | ||
Updated•25 years ago
|
Keywords: regression
Comment 1•25 years ago
|
||
I'm also seeing this ugly problem on my Windows ME JA. This problem
seems to be specific to Japanese fonts and Windows. Linux is OK.
It's very serious for japanese users because additional line is
inserted between each lines so we can not see the original messages
as sender expected.
Comment 2•25 years ago
|
||
I think this problem is serious.
If this problem haven't been fixed, Mozilla Mail is substantially useless in Japanese environment.
Comment 3•25 years ago
|
||
This bug is also happened on WindowsNT4.0.
I usualy use MozillaNews, but can't use for Japanese news groups.
I am having difficulty in this problem.
Comment 4•25 years ago
|
||
This also happens for messages with greek text (Build 2000122204 on Windows 98
Greek). I received a message with one paragraph in greek, which appears with
doubled newlines, and one paragraph in english, which appears correctly. I
attach the source of this message.
Comment 5•25 years ago
|
||
Comment 6•25 years ago
|
||
This is not mailnews fault. Sending to i18n. Upping priority. Looks like dogfood
to you?
Severity: normal → critical
Component: Mail Window Front End → Internationalization
Product: MailNews → Browser
Comment 7•25 years ago
|
||
This seems to be a display only problem for plain text mail.
As of 1/3/2000 Win32 build, I don't see extraneous blank lines
in Reply/Quote or Edit Message as New.
CC'ing Ben to see if he knows another bug like this one.
Summary: Linebreaks are doubled → Plain text: Linebreaks are doubled in mail view
Comment 8•25 years ago
|
||
When did this regress?
Can you please attach a test msg as mimetpye "message/rfc822" (the existing
attachment is garbled for me)?
Does it happen for reply or not?
Fabian, why do you think, it's not a Mailnews problem?
Reporter | ||
Comment 9•25 years ago
|
||
As far as I know, this regression occured between 12/5/2000 and
12/21/2000.
Comment 10•25 years ago
|
||
Ben AFAIK, this problem does not happen in Reply/Quote
btu it happens only when we try to view Japanese
plain text msgs. Instead of lines following one after
the other, we see something like this:
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
where xxxx..., yyy..., and zzz.... represent Japanese sentences.
with blank lines inbetween. We should display instead:
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Comment 11•25 years ago
|
||
Comment 12•25 years ago
|
||
Comment 13•25 years ago
|
||
Nikos's test case causes the problem on my WinNT4
with 1/4/2001 Win32 build.
I'll attach a screenshot.
Ben, can you try this on a Windows machine?
By the way, this problem is widely reported and
experienced by many users in Japan and so it should be
fixed ASAP.
Comment 14•25 years ago
|
||
Comment 15•25 years ago
|
||
See the comments above by Katakai-san:
Additional Comments From Masaki Katakai 2000-12-26 17:10
He reports that Linux does not suffer from this problem.
Do we know if the problem happens on Mac? Anyone with
additional Mac info, please write in comments here.
Reporter | ||
Comment 16•25 years ago
|
||
This problem doesn't happen if the message's "Content-Type" header
has "format=flowed".
Comment 17•25 years ago
|
||
momoi, oh, I overread it. Might be a line-ending problem.
Relevant checkins in Mailnews:
<http://bonsai.mozilla.org/cvsquery.cgi?dir=mozilla%2Fmailnews%2Fmime%2F&sortby=Date&date=explicit&mindate=12%2F5%2F2000&maxdate=12%2F21%2F2000>.
Nothing really suspicious. Seems like it's really the browser.
Comment 18•25 years ago
|
||
Here is what the plaintext code in Mailnews outputs for the body (you can easily
see it by clicking on the link with the latest testcase (which will open it in
the browser, nicely formatted) and then do View Source):
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family:
fixed; font-size: 16px;"><pre wrap>Î?αλημÎÏ?α Î?ίκο.
ΦανÏ?άζομαι ιÏ?Ï?Ï?ει η Ï?Ï?νάνÏ?ηÏ?η για Ï?ήμεÏ?α.
Î?Ï?ειδή θα βÏ?ίÏ?κομαι Ï?Ï?οÏ? Ï?α μÎÏ?η Ï?αÏ? Ï?ε λίγο
και δεν ξÎÏ?Ï? Ï?ι Ï?Ï?α θα
Ï?ελειÏ?Ï?Ï?, θÎλειÏ? αν Ï?ελειÏ?Ï?Ï? γÏ?Ï?Ï? Ï?Ï?ιÏ? 17:00
να Ï?ε Ï?άÏ?Ï? Ï?ηλÎÏ?Ï?νο να ÎÏ?θοÏ?με
Ï?αÏ?Îα Ï?Ï?ο ΠεÏ?ιÏ?Ï?ÎÏ?ι;
ειÏ? Ï?ο ειδείν,
Î?ιÏ?άληÏ?.
</pre></div></body>
The tags outputted for flowed are very different (no <pre> at all, IIRC), so
something in Layout may be horked. Reassigning there.
Assignee: sspitzer → clayton
Component: Internationalization → Layout
QA Contact: esther → petersen
Comment 19•25 years ago
|
||
Let me fill in on the background about format=flowed
for Mozilla.
When we implemented format=flowed for plain text mail,
we made msgs in multi-byte encodings (e.g. Japanese, Chinese,
Korean, etc.) to be format=non-flowed by default.
Single-byte encodings will get format=flowed by default.
This is why the problem described here is noticed by
msgs in Japanese. Since many other mail programs don't
yet generate format=flowed plain text msgs, you will
see this problem with msgs sent from other mailers
with non-Asian or Unicode msgs in it.
Comment 20•25 years ago
|
||
> Since many other mail programs don't
> yet generate format=flowed plain text msgs, you will
> see this problem with msgs sent from other mailers
> with non-Asian or Unicode msgs in it.
Thew above comment is inaccurate. Let me correct it to:
Since many other mail programs don't
yet generate format=flowed plain text msgs, you will
see this problem with msgs sent from other mailers
whether they use single-byte or multi-byte charset
as long as they lack format-flowed designation. E.g.
the Greek example from Nikos above.
Comment 21•25 years ago
|
||
I just want to add one comment to this: in the latest trunk builds i've noticed
that for plain text you are forced to the linebrake when you used a space bar at
least once when typing. If you didn't do so you are allowed to type the string
till the limit of the composition window.
Reporter | ||
Comment 22•25 years ago
|
||
Bug 63081 seems to be a related bug.
Comment 23•25 years ago
|
||
I'm not convinced it is not a mail-news bug.
putterman, should we take this from clayton until we figure out exactly where
the problem is?
I think we should.
Comment 24•25 years ago
|
||
seth, we need to get this bug moving quickly.
It is making it very difficult to read non-flowed
plain text messages for many users. Toward that goal,
if you can help pinpoint the cause, that would be great.
Comment 25•25 years ago
|
||
reassigning to ducarroz. cc'ing rhp. marking nsbeta1+ and moving to mozilla0.8
We can try looking into this.
Assignee: clayton → ducarroz
Keywords: nsbeta1
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.8
Comment 26•25 years ago
|
||
FYI win32 build 2000121204 does not have this problem. I reported pretty much
the same bug (63081) on build 121520. I can't confirm which build this actually
started with due to numerous xpcom.dll crashes on builds 121220 and 121304.
And I agree that this is a *serious* useability problem, since the majority of
my correspondence is with non-flowed plain text.
Comment 27•25 years ago
|
||
This is exactly the timeframe for Daniel Bratell's checkin. ccing him.
Comment 28•25 years ago
|
||
What checkin? I can't find any checkin done by me in the timeframe 12th of
December to 15th of December.
Anyway, I could look at it if only I could reproduce it. Can anyone attach a
message and complete actions to reproduce the bug? (A comment: to send all mails
format=fixed with Mozilla set the pref mailnews.send_plaintext_flowed to false)
Comment 29•25 years ago
|
||
> I can't find any checkin done by me in the timeframe 12th of
> December to 15th of December.
You're right - my fault. Your checkin is on the 19th.
There are no interesting checkins to libmime in the relevant timeframe.
> Can anyone attach a message
see above,
> and complete actions to reproduce the bug?
View it in Mailnews (anyhow import it in your folders, e.g. by overwriting an
exiting msg folder in the filesystem with the attached file).
Reporter | ||
Comment 30•25 years ago
|
||
Kato said aString.Mid() adds an extra newline.
Location: layout/base/src/nsPlainTextSerializer.cpp
void
nsPlainTextSerializer::Write(const nsAReadableString& aString)
..
..
else {
// There is a newline
nsAutoString stringpart;
aString.Mid(stringpart, bol, newline-bol);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comment 31•25 years ago
|
||
If nsPlainTextSerializer.cpp is where the trouble is,
then let's CC vidur, harishd and heikki. The file was last
modified on 12/12/2000 by vidru with r by harishd and heikki.
Comment 32•25 years ago
|
||
I wouldn't think that nsPlainTextSerializer is the guilty part. It shouldn't(*)
be involved in displaying of the mail. It only translates the display to text
when replying and correctly translates the double line breaks that are there
already.
One strange thing I notice is that the mail is displayed with double line breaks
in the mail viewer, but select and copy the text in the mail and paste it in the
composer. Now it's fine!?
I thought copy and paste should copy all the html so what's wrong? It's another
style sheet in the mail viewer but could that cause this?
(*) - One can never be sure. A lot of magic is done sometimes.
Comment 33•25 years ago
|
||
It means, nsPlainTextSerializer::Write does not see CR + LF conrrectly.
So stringpart value includes in "\r".
make sense??
Comment 34•25 years ago
|
||
I've looked at this and commented in bug 63081 (a dupe I would say). You're
right that it's the CRLF thats problematic. The parser used to replace CRLF
with just LF but doesn't anymore. That breaks nsPlainTextSerializer but also
other things so I rather see the main fix in the parser. I will patch
nsPlainTextSerializer also to be more robust, but that checkin won't be until
bug 62189 is checked in.
Comment 35•25 years ago
|
||
> The parser used to replace CRLF with just LF but doesn't anymore.
Do you know who did that? Can you reassign?
Comment 36•25 years ago
|
||
nevermind.
Comment 37•25 years ago
|
||
Common thinking is that it is a general parser bug and thus a dup.
*** This bug has been marked as a duplicate of 17686 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Comment 38•25 years ago
|
||
duh! marked as dup of wrong bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 39•25 years ago
|
||
*** This bug has been marked as a duplicate of 63081 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
verified dup.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 41•24 years ago
|
||
A similar problem is growing around quotation text.
Take a look at bug 67391.
You need to log in
before you can comment on or make changes to this bug.
Description
•