I was showing the emoticon feature to a friend, who is a email "purist". When he saw the emoticon, his words were, "I can turn that off, right?" so we need some UI in the prefs panel to turn that feature on or off, but we should have it on by default.
*** Bug 21067 has been marked as a duplicate of this bug. ***
See discussion on n.p.m.mail-news
accepting, marking m13
Not a beta stopper.
fixed. it's under Edit | Preferences | Mail and Newsgroups | Messages when tired, fix the easy bugs. you can turn on or off emoticon to glyphs and structs to style independently I'm sure we'll need better text in the pref dialogs to explain these prefs. since it is pretty advanced, we'll probably end up moving it to some advance panel
Seth, thanks for fixing this. However, the pref checking should be done by the caller, not mozTXTToHTMLConv, as it is not mail specific. The callers are currently mimetpla.cpp, mimetpfl.cpp and nsMsgSendPart.cpp, where the former two are for display of plain text msgs, the latter is for enhancing HTML Send. REOPENing. Shouldn't <http://lxr.mozilla.org/mozilla/source/mailnews/compose/prefs/resources/content/pref-messages.xul#97> also read |<html:input id="pref:1:bool:mail.convert_emoticons" type="checkbox"/>| as the default is on?
s/as it is not mail specific./as mozTXTToHTMLConv is not mail specific. You can use the mode param of ScanTXT to pass to decision to it.
thanks for the info about the callers, I'll fix it today. don't worry about the default for the pref in the xul file. the default for those prefs are true, and are set in mozilla/modules/libpref/src/init/mailnews.js
I've followed email@example.com advice and moved the pref calls from the stream converter to the callers. marking fixed.
1/4/2000 release build. Verified this for Win32. I tried various emoticons. I turned this pref off and there was no conversion. Then, I turned this pref on and reselected the message and saw the emoticons. (It shouldn't matter which product - 4.x or 5.0 - sent the message, right?) Need to verify on other platforms.
I'm going to file a new bug (if one doesn't exist) to move these prefs to a better location (if one exists) and for wording that may be better.
(New bug http://bugzilla.mozilla.org/show_bug.cgi?id=23091 entered for wording of prefs)
> It shouldn't matter which product - 4.x or 5.0 - sent the message, right? In this case, it does. It should give the same results, but it is different code. For sending: When you compose a msg and send it as HTML, emoticons should always be unchanged (regardless of the prefs, because the recipient doesn't have the icons), but the structured phrases conversion should be optional (default on). I just looked at the code for sending and it seems wrong to me. (I can't test it, as I currently don't have a running CVS mailnews.) If I'm right, here's a possible fix: <http://lxr.mozilla.org/mozilla/source/mailnews/compose/src/nsMsgSendPart.cpp#547> Change |PRUint32 whattodo = 0;| to |PRUint32 whattodo = mozITXTToHTMLConv::kURLs;| and the following emoticon pref checking to a structured phrases pref checking.
(Ben, I'll test the structured phrases separately since this bug report is for emoticons. As to your part about the code for sending structs being wrong, can you file a new bug on that? I would do it, but you would probably have more info to add to the bug report than me)
Filed bug #23330 about the wrong send flags.
UI present in Edit|Prefs|Mail and newsgroups|Messages. On/off causes incoming messages to be converted/not converted within session of changing pref state. Verified with 2000-04-07-09m15 commercial builds NT 4.0 and linux rh6.0