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

RESOLVED FIXED

Status

RESOLVED FIXED
17 years ago
10 years ago

People

(Reporter: lohphat, Assigned: sspitzer)

Tracking

({regression})

Trunk
x86
All
regression

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
Missing on Linux too. OS: All.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All

Comment 2

17 years ago
sspitzer
Assignee: neeti → sspitzer

Updated

17 years ago
Keywords: regression
Summary: text2html *bold* no longer working in mail/news → [TXT->HTML] *bold* no longer working in mail/news

Updated

17 years ago
Keywords: regression
Summary: [TXT->HTML] *bold* no longer working in mail/news → text2html *bold* no longer working in mail/news

Comment 3

17 years ago
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:

Updated

17 years ago
Keywords: regression
Summary: text2html *bold* no longer working in mail/news → [TXT->HTML] *bold* etc. and smilies no longer working in mail/news

Comment 4

17 years ago
(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?

Comment 6

17 years ago
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.

Comment 7

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

Comment 8

17 years ago
Mehmet: The negative powers problem is bug 91615.

Comment 9

17 years ago
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

Comment 10

17 years ago
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)
(Reporter)

Comment 11

17 years ago
Correcting the spelling of "offense".  ;-)

Comment 12

17 years ago
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

Comment 13

17 years ago
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.

Comment 15

17 years ago
<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>
(Reporter)

Comment 16

17 years ago
It was not meant to be serious. ;-)
Fix checked in 2001-11-06 20:12 PDT.  See bug 104651.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 18

17 years ago
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.

Comment 19

17 years ago
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.

Comment 20

17 years ago
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.

Comment 21

17 years ago
> 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.

Comment 22

17 years ago
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.

Comment 23

17 years ago
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 :(

Comment 24

17 years ago
> _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.

Comment 25

17 years ago
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?

Comment 26

17 years ago
> Then shouldn't this bug be reopened and made dependant on the stylesheet bug?

No, reporter was confused (compare "=)").

Comment 27

17 years ago
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
(Reporter)

Comment 28

17 years ago
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

Comment 29

16 years ago
-> 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.