Closed Bug 105459 Opened 23 years ago Closed 23 years ago

[TXT->HTML] *bold* etc. and smileys (emoticons) no longer working in mail/news

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: lohphat, Assigned: sspitzer)

References

Details

(Keywords: regression) 

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
sspitzer
Assignee: neeti → sspitzer
Keywords: regression
Summary: text2html *bold* no longer working in mail/news → [TXT->HTML] *bold* no longer working in mail/news
Keywords: regression
Summary: [TXT->HTML] *bold* no longer working in mail/news → text2html *bold* no longer working in mail/news
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:
Keywords: regression
Summary: text2html *bold* no longer working in mail/news → [TXT->HTML] *bold* etc. and smilies no longer working in mail/news
(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.
Summary: [TXT->HTML] *bold* etc. and smilies no longer working in mail/news → [TXT->HTML] *bold* etc. and smileys no longer working in mail/news
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.
Summary: [TXT->HTML] *bold* etc. and smileys no longer working in mail/news → [TXT->HTML] *bold* etc. and smileys (emoticons) no longer working in mail/news
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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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
Component: Networking → Mail Back End
Product: Browser → MailNews
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.