Closed Bug 63555 Opened 25 years ago Closed 25 years ago

Plain text: Linebreaks are doubled in mail view

Categories

(Core :: Layout, defect, P2)

x86
Windows 98
defect

Tracking

()

VERIFIED DUPLICATE of bug 63081
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
Keywords: intl
Keywords: regression
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.
I think this problem is serious. If this problem haven't been fixed, Mozilla Mail is substantially useless in Japanese environment.
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.
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.
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
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
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?
As far as I know, this regression occured between 12/5/2000 and 12/21/2000.
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
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.
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.
This problem doesn't happen if the message's "Content-Type" header has "format=flowed".
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.
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
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.
> 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.
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.
Bug 63081 seems to be a related bug.
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.
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.
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
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.
This is exactly the timeframe for Daniel Bratell's checkin. ccing him.
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)
> 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).
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); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
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.
It means, nsPlainTextSerializer::Write does not see CR + LF conrrectly. So stringpart value includes in "\r". make sense??
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.
> The parser used to replace CRLF with just LF but doesn't anymore. Do you know who did that? Can you reassign?
nevermind.
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
duh! marked as dup of wrong bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 63081 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → DUPLICATE
verified dup.
Status: RESOLVED → VERIFIED
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.

Attachment

General

Creator:
Created:
Updated:
Size: