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)
Tracking
(Not tracked)
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
Updated•23 years ago
|
Keywords: regression
Summary: text2html *bold* no longer working in mail/news → [TXT->HTML] *bold* no longer working in mail/news
Updated•23 years ago
|
Keywords: regression
Summary: [TXT->HTML] *bold* no longer working in mail/news → text2html *bold* no longer working in mail/news
Comment 3•23 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•23 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•23 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•23 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•23 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 9•23 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•23 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•23 years ago
|
||
Correcting the spelling of "offense". ;-)
Comment 12•23 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•23 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-]
Depends on: 104651
This is fixed by the patch I'm going to attach to bug 104651 shortly.
Comment 15•23 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•23 years ago
|
||
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
Comment 18•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 years ago
|
||
> Then shouldn't this bug be reopened and made dependant on the stylesheet bug?
No, reporter was confused (compare "=)").
Comment 27•23 years ago
|
||
Reporter | ||
Comment 28•23 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•22 years ago
|
||
-> mailnews qa
Component: Networking → Mail Back End
Product: Browser → MailNews
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•