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>
*** 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.
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.
Adding keyword for parity "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.
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!
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.
I just tested this on Friday's release build on the Mac and it seems all better now :-) - rhp
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....
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
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...
Sure, this bug doesn't append with a Mozilla debug build from this morning!!!
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)
I have an idea on how to do this. - rhp
Checking in a fix for this. - rhp
Verified as fixed on Mac using the build: macos commercial seamonkey build 00052208-m16 installed on G3/400, MacOS 9.04