Closed Bug 38555 Opened 24 years ago Closed 24 years ago

Mail body displays html codes.

Categories

(MailNews Core :: MIME, defect, P3)

PowerPC
Mac System 9.x
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cwang, Assigned: rhp)

References

Details

(Keywords: platform-parity, Whiteboard: [dogfood+])

Build: 2000-05-08-08 comm build:

Steps to reproduce:

1. Sign on IMAP mail account
2. Input either English or Japanese characters(make sure it is html)and send.
3.Click get Msg and display.

actual result: you will see the following is displayed <!DOCTYPE HTML PUBLIC 
"-//W3C//DTD HTML 3.2 Final//EN">
<html><head></head><body>の飽き直木</body>

Expected result:html codes shouldnt be displayed with the message sent.
</html>
Summary: IMAP Mail body displays html codes. → IMAP Mail body displays html codes.
Severity: normal → major
Keywords: dogfood
QA Contact: lchiang → pmock
*** Bug 38556 has been marked as a duplicate of this bug. ***
per Fenella, IMAP only; displaying POP messages are fine.

No problem with Win32. Unable to test Linux due to another bug.
Severity: major → critical
cc'ing ducarroz.  Jean Francois, is this happening in your build?
I cannot reproduce this problem on my Mac with adebug build from this morning 
7:30 am. I've tried sending HTML message in HTML format as well HTML message 
converted in plaintext without problem.
JF - this happens in today's commercial build. I wonder if it's a mozilla vs. 
commercial type of bug.
I can reproduce this problem using today macos commercial seamonkey build 
2000-050808-m16 installed on a G3/400 running MacOS 9.04.

Steps to reproduce problem:
0) I deleted my previous 5.0 user profile
1) Installed todays commerical seamonkey build.
   I used the .sea file found at:
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/2000-05-08-08-M16/Netscap
e6-mac.sea.bin
2) Launched seamonkey build
   The browser build id found at the lower right corner was 2000050808
3) Open Messenger
4) Select the Inbox and log into mail
   I was configured for IMAP
5) Start a new mail message
   A HTML compose window appears
6) Address the message to yourself and enter in a title
7) Types some text in the message body area
   Don't add any rich text.  Leave the text as plain.
8) Send message
   You should not be prompted to choose between
    - send html & plain, - send html only, or send plain text only
9) Retrieve this mail message in 5.0 or 4.7x
10) View the message
    The content-type will show "Content-Type: text/plain; charset=us-ascii; 
format=flowed"
    HTML tags will be displayed in the message body.  The body didn't get 
converted to 7 bits.

** I believe there is a problem with the conversion between HTML -> Plain text 
because, if I did have rich text in the message body and selected to choose 
"send plain text only", I will get the same results.  

This problem does not occur todays linux or win32 builds 2000-0508 builds.
Hardware: PC → Macintosh
Adding keyword for parity "pp"
Keywords: pp
cc: nhotta and ben since they were working on some bugs in this area (?)
My recent changes are for plain text view only.
If the view is broken in 4.7x then probably not related to my changes.

Yes, I would say that something is broken during the sned process. Maybe the 
HTML to plain text conversion failed?
Putting on [dogfood+] radar.
Whiteboard: [dogfood+]
Target M17.
Target Milestone: --- → M17
This bug is a dogfood+ bug so it has higher precedence than feature and other
stuff. Re-targeting to M16. rhp, when you have a chance, can you put a date
estimate in the whiteboard as to when you think you might have a fix for this?
Thanks!
Target Milestone: M17 → M16
Yes, I'm doing bug triage today as well as prioritizing my work. Will, 
reshuffle today.

- rhp
-- Additional Comments From Akkana 2000-05-16 17:08 in bug 39508 --
> Apparently something changed recently which broke the handling of flags inside
> the nsDocumentEncoder -- cmanske reported a similar bug with the
> OutputSelectionOnly flag not being followed.

Might be related (nsHTMLToTXTConv).
I'm on it.
Status: NEW → ASSIGNED
I just tested this on Friday's release build on the Mac and it seems all better 
now :-)

- rhp
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Rich,
I just tried yesterday Mac commercial seamonkey build, 2000-051608-m16 and the 
problem still occurs on the Mac. 

Re-openning bug for consideration....
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The conversion from 
  HTML to HTML -> works as expected
  HTML to Plain text only -> fails (HTML source code displays in msg pane)
  HTML to Plain text and HTML -> fails (looking at page source, plain text 
portion has not been converted to plain text)
ok...text conversion is horked on Mac. I won't be able to look at this until I 
get back home and can debug on the mac.

- rhp
Status: REOPENED → ASSIGNED
Checked 2000-05-18-10 comm build:
Partially fixed.
Only "Send in Plain text only" in the HTML Mail question dlg box failed for both 
IMAP and POP. Others: "send in Plain and html" and "Send in html only" work 
fine. 
I take it...
Assignee: rhp → ducarroz
Status: ASSIGNED → NEW
Sure, this bug doesn't append with a Mozilla debug build from this morning!!!
Status: NEW → ASSIGNED
I was able to reproduce the problem with a Mozilla Release build I built myself. Therefore I can say that it's not a 
Packager or a Commercial build issue. Now, the chasse can start...
The problem comes from nsURLFetcher::OnStopRequest where the channel return a bogus content type  
(nsURLFetcher.cpp, line 264). We are currently processing a file URL on a temp file (nsmail-n.tmp)

With a Mac debug build, I get "text/cpp". with a Mac release build, I get "text/plain". Apparently on Window we also 
get a bogus type (unknown). But as long the type is not "text/plain", we are able to correclty convert the HTML body 
to plain text. The correct content type should be "text/html"

Rich, can you take over? (as I am on vacation until June 11)
Summary: IMAP Mail body displays html codes. → Mail body displays html codes.
I have an idea on how to do this.

- rhp
Assignee: ducarroz → rhp
Status: ASSIGNED → NEW
Checking in a fix for this.

- rhp
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Verified as fixed on Mac using the build:
  macos commercial seamonkey build 00052208-m16 installed on G3/400, MacOS 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.