mail doesn't show newlines

VERIFIED WORKSFORME

Status

MailNews Core
Networking
P2
normal
VERIFIED WORKSFORME
18 years ago
10 years ago

People

(Reporter: Henrik Gemal, Assigned: Scott MacGregor)

Tracking

Trunk
All
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+])

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
I have a mail with:
Content-Type: text/plain; charset=us-ascii

and the text in body gets wrapped into one line, without any newlines.

Example can be seens at my mailserver. lchiang has username and password. Just 
mail me and you can see for yourself.
(Reporter)

Comment 1

18 years ago
This could be related to bug 43078

Comment 2

18 years ago
Please attach the msg source (save as eml), content type message/rfc822.
(Reporter)

Comment 3

18 years ago
Created attachment 11919 [details]
mail that renders without any linebrakes
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: correctness, nsbeta3
Target Milestone: --- → M18

Updated

18 years ago
Keywords: mail2

Comment 4

18 years ago
Peter - can you reproduce this?
QA Contact: lchiang → pmock
Whiteboard: [nsbeta3+]
(Assignee)

Comment 5

18 years ago
Hmm I'm not sure how to fix this bug. cc'ing rhp. I just stepped through this in
the debugger.

We are preserving the CRLFs when we hand the message body data off to the input
stream that layout consumes. So it's nothing on our end in that regard.

Here's what I think is going on:
1) layout is expecting text/html because we told it that's what we were going to
feed it for the message body.
2) the real content of this message is text/plain.
3) when displaying html. CRLFs are meaningless. They are treated as white space.
You need to use <br> to properly get line breaks.

I wonder if our problem is that we are feeding this text/plain document into an
html parser and it's ignoring the CRLFs?

Comment 6

18 years ago
Sorry for the late response:
 Yes, this issue is reproducible on all platforms
  win32 commercial seamonkey build 2000-080909-m18
  linux commercial seamonkey build 2000-080808-m18
  macos commercial seamonkey build 2000-080908-m18

Changing platform to all.
Hardware: PC → All

Comment 7

18 years ago
I thought all mails went through the mime decoders which turns them into HTML? 
In the case of ordinary text/plain they just used to be wrapped in <PRE>. Ben 
has made it a lot more fun since then, but every mail should still be converted 
to HTML.
(Assignee)

Comment 8

18 years ago
Created attachment 12716 [details] [diff] [review]
log file showing the html mime generates for the message body

Comment 9

18 years ago
So there is 
<div class=text-plain wrap=true graphical-quote=true style="font-family: Times 
New Roman; font-size: 16px;"><pre wrap> 
mail
</pre></div>

This really sounds like something shouldn't rewrap. Henrik, could you try to put 
you mail in those tags and load in the browser and see what it does with it?

Cc:ing Ben.
(Reporter)

Comment 10

18 years ago
Couldn't it has something to do with bug 41637 ?

Comment 11

18 years ago
P2 per mail triage
Priority: P3 → P2

Comment 12

18 years ago
Peter - is this reproducible on other types of msgs besides Henrik's?  Trying 
to see if this is a common situation for someone to run into.
(Reporter)

Comment 13

18 years ago
The message seems to render just fine now. Please verify!

Comment 14

18 years ago
good news.  Then, I'll mark wfm so pmock can verify.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 15

18 years ago
Verified as worksforme on win32, linux, and macos using the following builds:
 win32 commercial seamonkey build 2000-091906-m18 installed on P500 Win98
 linux commercial seamonkey build 2000-091906-m18 installed on P200 RedHat 6.2
 macos commercial seamonkey build 2000-091904-m18 installed on G3/400 OS 9.04

Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.