68212 - SEND PAGE: HTML pages are sent as raw HTML code, not rendered

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P2)

Description

[Jaime Rodriguez, Jr.]

Build ID: 2001020804
Reproducible: Frequently

Steps:
1. Launch N6
2. Enter http://news.cnet.com/news/0-1005-200-4755462.html into the location bar
3. Select 'Send Page' from the File menu.
4. Enter mail addresses into the mail compose window.
5. Click on the Send button.

Results: eMailed  article is sent as raw HTML code.

Note: Please see email sent to Ester.

Comment 1

[(not reading, please use [e-mail] instead)]

over to ducarroz.

Comment 2

[(not reading, please use [e-mail] instead)]

I just tried this on my mac, and it worked fine.

weird that it is not reproducable 100% of the time.

are you sure we aren't sending it properly, or that we aren't displaying it
properly.

I bet it is a problem with not displaying it properly, and we lose the content
type on the channel.  (we've got a few bugs like that, especially on news.)

this was read in your IMAP account, not POP right?

once you get into this state, can you see if switching folders fixes it?

if I'm right, it is a bug for mscott, not ducarroz. but I'll want to hear from
jaime before re-assigning.

Comment 3

[Jaime Rodriguez, Jr.]

~ Seth

Actually, I've seen it both in my saved Send folder, and well as on the
recipient's Inbox. Does that help? Do u need to come see my box???

Comment 4

[(not reading, please use [e-mail] instead)]

the recipients inbox?  is it 100% reproduce in their inbox?  what mail client
were they using?

Comment 5

[(not reading, please use [e-mail] instead)]

adding myself to the cc list so I can get jaime's response.

Comment 6

[sairuh (rarely reading bugmail)]

i also see this on linux [2001.02.09.08 comm bits]. here's a testcase:

0. i'm using a migrated profile that's been setup to us IMAP. also have turned
on the pref [in Acct Settings] to use compose msgs in HTML.
1. within a browser window, go to http://www.kith.org/
2. select File > Send Page --i addressed the email to myself in the mail compose
window.
3. send the email.
4. in the mail [3pane] window, click Get Msg button and select that email to
view it.

expected: when viewing the email, the attached page should be rendered like a
webpage.

result: when viewing the email, the attached page is displayed as html
[plaintext] source. in fact, it's displayed this way in both N6.x and N4.7x.
will attach screenshots.

Comment 7

[sairuh (rarely reading bugmail)]

Attachment: email sent from N6.x displayed incorrectly in N6.x

Comment 8

[sairuh (rarely reading bugmail)]

Attachment: email sent from N6.x displayed incorrectly in N4.7x

Comment 9

[(not reading, please use [e-mail] instead)]

thanks for the test case, sarah.

I was confused.  I thought this was like bug #59449 (see that bug for a screen
shot)

ducarroz seems like the proper owner for this.

Comment 10

[scottputterman]

I've been able to reproduce this and have seen a bunch of reports about this.
Putting on mozilla0.9 radar.

Comment 11

[fenella]

This is Sheela's area now.

Comment 12

[Jean-Francois Ducarroz]

I can also reproduce that with a Windows build from 2001020220. For some reason, the content type of the 
attachment (the page your are sending) is set to text/plain instead of text/html. This is a message compose bug.

Comment 13

[Jean-Francois Ducarroz]

I know what's the problem. I've accidently ifdefed code on non Mac platform (nsMsgAttachmentHandler.cpp, line 402). 
I'll attach a patch soon...

Comment 14

[Jean-Francois Ducarroz]

here is the fix:

Index: nsMsgAttachmentHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/compose/src/nsMsgAttachmentHandler.cpp,v
retrieving revision 1.64
diff -w -u -4 -r1.64 nsMsgAttachmentHandler.cpp
--- nsMsgAttachmentHandler.cpp	2001/02/07 06:52:20	1.64
+++ nsMsgAttachmentHandler.cpp	2001/02/14 23:16:12
@@ -398,19 +398,19 @@
 
   if (ma != nsnull)
   {
     ma->m_size = totalSize;
-#ifdef XP_MAC
     if (aContentType)
     {
+#ifdef XP_MAC
       //Do not change the type if we are dealing with an apple double file
       if (!ma->mAppleFileSpec)
+#endif
       {
         PR_FREEIF(ma->m_type);
         ma->m_type = PL_strdup(aContentType);
       }
     }
-#endif
 
     if (aCharset)
     {
       PR_FREEIF(ma->m_charset);

Comment 15

[Jean-Francois Ducarroz]

we should consider this fix for Mozilla 0.8 if it's not too late.

Comment 16

[Scott MacGregor]

sr=mscott

Comment 17

[(not reading, please use [e-mail] instead)]

r=sspitzer

Comment 18

[(not reading, please use [e-mail] instead)]

asa has given this a=asa for 0.8, but you got to do it quick, the train is
leaving in 15 minutes.

Comment 19

[Jean-Francois Ducarroz]

Fix checked in the Mozilla 0.8 branch

Comment 20

[(not reading, please use [e-mail] instead)]

and the trunk?

Comment 21

[Jean-Francois Ducarroz]

Checked in the trunk too.

Comment 22

[Sheela Ravindran]

verified commercial trunk build and will verify on branch when it is available.
 Leaving bug as resolved fixed untill verify it on branch.
buildid:  2001021908 linux
          2001021904 mac
          2001021908 win98
 

Comment 23

[Sheela Ravindran]

Marking bug as verified according to Paul Wyskoczka and see the builds in the
comments above.