win32 2001101803 on win2kpro-sp2 This may be related to the fix for 104693. Send a text/plain mail to yourself with: *test* _test_ =) ;-) :-) None autoHTMLify.

Missing on Linux too. OS: All.

sspitzer

No, it is not related to fix of bug 104693 (sorry, as I suggested it). It rather may have similar reason as the regression happened between the morning builds of October 11 and 15. That is it may be one of the following check-ins (both were suspected also on bug 104693, one wrongly): 1.47dbaron%fas.harvard.eduOct 12 21:25 Fix Sun WS 5.0 bustage by moving conditional deeper into expression. b=100214 1.46alecf%netscape.comOct 12 17:12 convert from nsCRT::strn?cmp to Compare() for bug 100214 r=jag, sr=sfraser I see both check-in authors are already in the CC:

(somebody stomped over my changes)

This one was caused by alecf's change in rev 1.46 -- perhaps because of the N not comparing null issue I mentioned in bug 104693?

We'll just fix this the right way, I'll bet its the null issue. From Ben, so we don't have to keep referencing the other bug: > Most likely, the bug is in either function > mozTXTToHTMLConv::CompleteAbbreviatedURL or mozTXTToHTMLConv::ItMatchesDelimited. its probably ItMatchesDelimited.

Hi, I know this is alittle Offtopic but it also displays 10^2 correctly but 10^-2 and 10^3.14 incorrectly

Mehmet: The negative powers problem is bug 91615.

Correcting the spelling of smileys to allow people finding this bug. No offence meant.

small testcase for smileys: : :- ; ;- P :P :-P ;P ;-P D :D :-D ;D ;-D ) :) :-) ;D ;-D :P, ;P, ;-P, :D and ;D aren't detected as smilies, but I really think they should be. (just my $0.02)

Correcting the spelling of "offense". ;-)

Thanks lohphat. However, the issue was real. On netscape.public.mozilla.org newsgroup there is an ongoing discussion on this smileys/emoticons problem. Reading it, I was surprised that people could not find this bug. As this meant that at least one duplicate bug was about to be filed, I decided to make it easier to find this bug by correcting the very world one would try to use in searching. Per the same line of thinking I add "emoticons" to summary.

Single letters should not trigger smileys <period>. imo not having a mouth doesn't consistute a face so it should not trigger 'smileys' <g> As for :-P a long time ago i was surprised that we didn't recognize it but i didn't care much. B-) B-> ;-b >;-p ;^b B-]

This is fixed by the patch I'm going to attach to bug 104651 shortly.

<qa_ignore> Lohphat: Offence is the British counterpart of American offense. I learned this version of English at school. Bugzilla is an international page, so please do not discriminate against European (and BTW Canadian) users. So whatever the colour of your flag, show the sense of humour and take no offence. Do me the favour and be a good neighbour. All right? </qa_ignore>

It was not meant to be serious. ;-)

Fix checked in 2001-11-06 20:12 PDT. See bug 104651.

Trunk build 2001-11-20-03: WinMe fyi: I typed some bold text followed by ":-)", after a send/receive the smiley appears as text. I would have expected to see the graphic.

nbaca, you mean *this smily :-) here*? I might have coded it intentionally this way to prevent loops in wierd edge cases or something like that. File a bug, if you care about this case.

nbaca and others reporting this now see that if there is bold text (or possibly other HTML attributes)in the body of a mail message with a smiley in plain text :) the smiley appears as plain text when received. If, we just have plain text in the message body and a plain text smiley we recieve a smiley emoticon. Basically what the summary states. This bug was not verified yet, so we think it's still broken in Mail compose.

> Basically what the summary states. I think you misinterpreted it. This bug was about the fact that *neither* bold *nor* simlies were recognized, *all* of the time. What you are saying seems to be that the *combination* of them doesn't work. This is a completely different bug and might have been all the time this way.

Ben, yes you are right. I did misinterpreted the summary. And yes you are right, the behavior nbaca and I see happened back in 6.2. I need to find the spec for smiley's to see if this is the correct behavior. Thanks for the clarification.

I don't think this bug should be marked as fixed until all commonly used formatting styles mentioned in the summary work properly ("*bold* etc."). Particulraly, I mean: *bold* <-- works /italics/ <-- doesn't work? _underline_ <-- doesn't work! Please reopen, if any of the above still do not work. PS. I can't test it right now because my Mozilla installation is irreparably broken right now :(

> _underline_ <-- doesn't work! This never worked, due to a stylesheet problem. It's another bug. /em/ should work, if *strong* works. I don't think that =) ever worked or should work.

Then shouldn't this bug be reopened and made dependant on the stylesheet bug? Otherwise, we are implying here that the bug has been fixed when it has not. PS. Anyone know what the stylesheet bug# is that would fix the _underline_ problem?

> Then shouldn't this bug be reopened and made dependant on the stylesheet bug? No, reporter was confused (compare "=)").

Does the nobele art of searching for bugs vanished completely? ;-) Esther: "Text formating (bold, italic, underline) deletes smiley" is bug 83501 Ben: "Capability to _underline_ words" is bug 74248

WRT "=)" not being a smily, may I suggest as an RFE a section in the prefs which contain a default set of smiley mappings, and the option to map custom sequences to the existing graphics? Can't we all just get along? ;-) :-) :-( ;-( :-/ :=\ >-p

-> mailnews qa