1. Smilies must not be substitued at HTML send (like now), because the recipient might not have the images. 2. URLs are not linkified 3. Structured phrases prefs are ignored (always off).

This should fix it. Seth, can you review and check in? Tnx.

Ben, to verify, does this mean that if I use html compose (new msg or reply) which has a smiley in it and send the msg, when viewed in 5.0, the msg should have a :-) emoticon in it? And when viewed in 4.x, the smiley should not be an image? Because right now, I think if the msg is viewed in 4.x, we show a blank area where the smiley should be.

Lisa, exactly

Thanks. I thought rhp or mscott had a bug on this already? At any rate, we have this bug to track now!

Neither of them have a bug on then issue.

testing benb's patch now. if it works, I'll check it in shortly.

I checked in this patch, but then I backed it out. there is a problem with this patch. the section of code that you are patching is wrapped with an #if 0 and there is a comment: // This part has moved to nsMsgSend.cpp you may want to ask rhp for where to make the right fix.

Sorry, I forgot bug #22315, I'll create a new patch.

ok, I'll review and do a quick test, and if all looks good, I'll check it in as soon as the tree opens.

ok, it looks good, but I have questions / comments. 1) we always convert urls on send. at first, this didn't make sense, since mozilla, when viewing a message, would convert urls to html links. but doing it this way is good, for other mail applications who don't do the conversion from url to href html. one could argue that we shouldn't do this, since a) it modifies the original message. I don't mind modifying messages from rfc/822 to html at display time, but modifying on send is a little scary. b) converting urls hrefs at display time is a "feature" of mozilla, if another mailer doesn't do it, that would be a reason to switch to mozilla. 2) we never convert emoticons on send, which makes sense, since other mailers won't have the chrome:// urls to our gifs. we do this on decoding. this is the original bug, and appears fixed now. 3) based on prefs, we convert structs to html. again, see point 1. we are modifying 4) the ui for the convert struct pref has to be changed to reflect that the pref is not only a view message pref, but a send pref. I'll check benb's changes in, since it fixes the bug, but I have reservations about changing urls or structs at send time. I'll open a new bug on that for discussion.

checked in. marking fixed. I also took the liberty of removing the dead code from nsMsgSendPart.cpp

Bug #23582 is about the new prefs.