User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4) Gecko/20030624 :-b has no corresponding icon whereas :-) and other smileys have one. Reproducible: Always Steps to Reproduce: 1. Compose an email with this simley and other more popular ones 2. Look at it in the folder. Actual Results: Most of the simleys are replaced by an icon, but :-b has no replacement icon. Expected Results: IL would like to have an icon displayed for this smiley too.

Is that smiley somehow semantically different than using capital-p? :-P

This is just another example of the injustices the right-tongued people of the world (:-b) have experienced under the crushing might of the left-tongued oppressors (:-P)!

I think this is a legitimate bug, despite being ever so small.

Invalid bug: tongue-out smiley not supported. Valid enhancement bug: show :-b as tongue-out smiley. Altering bug to make it the latter. URL is possible location of needed fix.

:-] smirk :-} grin are also not implemented (http://www.faqs.org/rfcs/rfc1594.html). Lastly, it would be wise if the nose were made optional. i.e. :) = :-) Most Forum software doesn't require it, hence many individuals don't remember the nose. As a result, half of emails are rendered with an image, half without. I think this bug would go nicely hand in hand with bug 217855 (just entered). Perhaps a smiley overhaul, since Mozilla is happy about it's new independance.

Patch to remove case sensitivity in making smilies (Most other apps like AIM don't care if it's :-P or :-p it treats it the same), as well as added :-b although, it maps to the same image. I hope to write a patch and add a few more emoticons that are common in the near future, but this is good enough for now.

Comment on attachment 140912 [details] [diff] [review] Patch v1 Review denied, sorry. The cases should be grouped for s4, just like you did for s7.

Patch v2 - Got 8hrs sleep, so I see a bit more clearly, I believe I addressed Daniel's Comment - Few more things that I don't think need to be case sensitive

Damn. Don't know why that was the one I attached. Wrong patch (obvious mistake). This *should* be better.

Comment on attachment 140968 [details] [diff] [review] Patch v2.1 r=daniel@glazman.org for the editor underlying chrome code. Please do __NOT__ check this in without prior approval/review of the mailnews people, sspitzer or mscott; thanks.

sorry for spam, I forgot to say thanks for fixing non-really-empty lines and extra trailing spaces :-)

sspitzer, mscott, can you please give a glance at the proposed change ? It's harmless from an editor's point of view but since you're almost the sole client of that code, your a/r/sr is highly welcome here. Thanks :-)

My editor ConTEXT fixes those on it's own :-D (perhaps I can see if it's possible to do for a batch group of files?) I don't have commit, so it's up to you, sspitzer, or mscott to checkin. If it's alright with everyone, at some point, I'd like to add a few more "popular" emoticons, though that would be another bug. Would be a nice little enhancement. I think I filed a bug on that way back when, I guess I should dig that up.

Comment on attachment 140968 [details] [diff] [review] Patch v2.1 I'll check this in

checked in to 1.7b trunk

Can anyone verify this either way?

This bug still isn't fixed in a build from yesterday. I still see the same as on the screenshot Robert attached. :-b and o:-) aren't converted to graphical emoticons. Isn't method GlyphHit() in netwerk/streamconv/converters/mozTXTToHTMLConv.cpp the correct place to fix this bug?

I'll have a patch later this morning, or towards the end of the afternoon, whatever comes later.

This should take care of the missing testcases I saw the other day.

Sorry for bugspam. Note this patch conflicts with the patch for bug 84950. Since I'm not accounting for that change. Most likely, I'll need to redo it after that checkin. Unless Scott wants to just merge them into 1.

I don't think this is a good idea. The TXT->HTML converter wasn't intended to find any and all smilies, that's actually impossible: <http://paul.merton.ox.ac.uk/ascii/smileys.html> <http://www.cg.tuwien.ac.at/~helwig/smileys.html> ... Thus I leave it up to the user to figure out most of the smileys. As you can see from the code, it's therefore not made to support vast arrays of smileys. Other smileys recently introduced are ambiguous, for example :-X is used by some for a kiss. The intention was only to find a very small selection of the most-used, most well-known, unambiguous smileys.

Well, the goal for this bug was to mimic AIM, or MSN's overlap. And compensate for the complete domination over smilies that BBS's like UBB or phpBB, vb have had over emoticons All aren't case sensitive. Hence :-P = :-p for example. Or even :-b (not as popular, but it still happens, and is supported by other apps). The goal was to allow users to have the feature as transparent across products as possible. It's mozilla that's out of the loop, as I haven't seen any other app that doesn't recognize the alternates. Granted, we can never support all emoticons. I have a list of literally a few thousand. That's excess. But we should support the very popular ones (a few are missing see bug 155028 for that). We should also support them in the same manner as any other product. I'm not going to push for support of 10,000 emoticons internally :-D as fun as that would be. But our support should be transparent with other popular applications like AIM, MSN, Yahoo IM, and the various forum software out on the net.

> the goal for this bug was to mimic AIM, or MSN's overlap. ... > our support should be transparent with other popular applications > like AIM, MSN, Yahoo IM I disagree. IIRC, we had smiley support before MSN Messenger even existed. "Microsoft does it" is no reason for me at all. > But we should support the very popular ones Agreed. I'd say that ;-p (in contrast to ;-P ) is not very popular.

(In reply to comment #23) > > the goal for this bug was to mimic AIM, or MSN's overlap. ... > > our support should be transparent with other popular applications > > like AIM, MSN, Yahoo IM > > I disagree. IIRC, we had smiley support before MSN Messenger even existed. > "Microsoft does it" is no reason for me at all. > > > But we should support the very popular ones > > Agreed. I'd say that ;-p (in contrast to ;-P ) is not very popular. Well, if I query my email, I'd get dozens of hits in the past year just for :-p. It's very popular because every other application that does smilies allows it. Why press shift? End users won't always be doing this. No other application that I am aware of, and tested is case sensitive. Fact is end users, that aren't techies lurking IRC and the newsgroups don't know, or care to know about case sensitivity and smilies. They don't know the millions either. They know what AOL and MSN taught them. If we want to look complete to end users, we need to show that we are not only equivilant, but better. Nobody else is case sensitive. Forums, the place where emoticons are most overused, doesn't even care about a nose. Hence :-) = :), ;-P = ;P. If we really wanted to get cool about smilies, and amaze the end users, this would be a separate RFC, but I'll mention it here briefly: We should assemble the emoticon from separate images of characteristics based on: http://bugzilla.mozilla.org/attachment.cgi?id=143512&action=view So for example: :-P Would mean: Standard Eyes Standard Nose Tongue out of mouth ;-P would mean: Winking Eyes Standard Nose Tongue out of mouth In theory, with 30 or so smaller image parts, latered to create smilies, we could revolutionize the smiles feature. Again, this would be some work, and it's a whole other RFC, but it's just a thought, perhaps something to explore at a later date. By making each element separate, Mozilla could analyze and reproduce most popular emoticons per commonly accepted meanings. ------------------------------------- My ultimate goal with these handful of emoticon bugs I have going here is to make the experience universal across products. So that an enduser gets the same quality of experience across the board. We need to keep with the times.

Ok, I'm going to need a review and sr here. We've got a patch checked in to implement the functionality. The suplimential patch is just to finish it, and make it consistant.

> if I query my email, I'd get dozens of hits in the past year just for :-p. You *would* get? You didn't even make the query? I just did make a query for ";-b", over *all* my 160000 emails, and you know what? I got exactly 1 hit, and that was an artifical testcase.* This is very strong evidence that this smiley is *not* extremely popular (and that's needed to get into the converter) and the "judgement call" I spoke about is very much in disfavor of it. * Comparison: 13 hits for ";-p", 700 hits for ";-P", 7700 for ":-)". Context not considered in all cases. (Phew, my poor mail server.) So, the 'misspelt' smiley ;-p is used almost 2 orders of magnitude (!) less frequently than the 'real' one ;-P, and almost 3 orders of magnitude less frequently than the original smiley. I thus WONTFIX this, at least as far as the converter is concerned. Because there's a patch checked in, this bug was already marked fixed, and you just reopened it, I'll restore the FIXED state. For the future: If you make any other patches for the converter (mozTXTToHTMLConv.cpp), let me review them.

> * Comparison: 13 hits for ";-p" That's less than one in 12000 emails, which is definitely *not* enough. Actually, the majority of them are even testcases and e.g. bugmail from this very bug, only 4 (!) of them in the wild. It would make more sense to build a smiley for the word "Robert" into the software than for ";-p".