94791 - Smilies in HTML message are not displayed as graphics

Status: NEW

(MailNews Core :: MIME, enhancement)

Description

[marina]

**** observed with 2001-08-09 build ****
Steps to reproduce:
- compose an html mesage with :-) in it;
- send message, get it, select it;
- Reply and Forward the message;
//note: in Reply case you have them displayed as grahics, in the forward message
they are not converted

Comment 1

[marina]

i forgot to mention that it apllies only to the forwarding inline

Comment 2

[scottputterman]

reassigning to ducarroz

Comment 3

[Jean-Francois Ducarroz]

WFM using recent build on windows

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

No, this doesn't work for me with build 2002-01-10-03.  Re-opening (Windows 2000).

Comment 5

[selmer (gone)]

Apparently broken on reply as well.  (I replied to a forwarded message and added
an emoticon in my reply text.  As a recipient of the message, I see that the
emoticon was not converted.)

Comment 6

[selmer (gone)]

Attachment: Pref set to show emoticons, message doesn't show them.

Comment 7

[Katsuhiko Momoi]

Is there any progress on this bug?

In my case, if the MIME is single part plain/text msg, it does show the 
emoticon but it does not show it if if is multuipart/alternative. So if a
message is of this type:

===========================================

Content-Type: multipart/alternative;
 boundary="------------020800060105040309040805"


--------------020800060105040309040805
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

this is :-)

-- 
Katsuhiko Momoi <[e-mail]>


--------------020800060105040309040805
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

....
....
===========================================

the emoticon display does not work. 

Do you have a code that will display emoticons only if it
can detect simple plain/text msgs?

Comment 8

[Katsuhiko Momoi]

Maybe, I should file a new bug because my case has nothing to do with
forwarding. The problem occurs on multipart/alternative msgs. Many msgs
are like that and so this is a very visible problem. Let me
know if you want a new bug.

Comment 9

[Jean-Francois Ducarroz]

Momoi, yes please file a new bug.

Comment 10

[Ben Bucksch (:BenB)]

Please cc me on that recognizer stuff.

This is not a bug. I think you are all talking about HTML msgs, not plaintext
msgs, and smilies don't work in HTML msgs. Never did.

We don't do recognition stuff on HTML msgs on the recieving side. For HTML, the
recognition should work on the sending side. It does for URLs, it
can be done for structs (but you chose to disable that by default). It can
hardly be done for smilies, because we can hardly send images in the msgs just
to have fancy smilies. Maybe we find a better solution for that.

I still think that we shouldn't run recogitions on incoming HTML. We could, but
that somewhat defeats the whole HTML idea (unambiguous content, clearly marked
by the author).

We might be able to insert an <img src="chrome://..." alt=":-)"> or similar, but
that's ugly, because it will probably break some clients more or less and even
if it works, the graphical smily will only appear in Mozilla.

Unless somebody can come up with an interoperable and nice way to represent
graphical smilies in HTML, or some other good solution, this should probably be
WONTFIX.

Comment 11

[Ben Bucksch (:BenB)]

I forgot to add: In my testing, it all worked fine whenever the smily was in a
plaintext msg, either forwarded inline in a plaintext msgs or forwarded as
attachment. It only didn't work when you forwarded inline in a HTML msg.