Closed
Bug 67981
Opened 24 years ago
Closed 24 years ago
unable to insert emoticons (two cases)
Categories
(Core :: DOM: Editor, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: sspitzer, Assigned: anatoliya)
References
Details
Attachments
(2 files)
6.01 KB,
patch
|
Details | Diff | Splinter Review | |
6.13 KB,
patch
|
Details | Diff | Splinter Review |
bring up html message compose
add a emoticon, like :), using the emoticon picker. it works
try to add a second one, nothing gets added.
if I type a space, then another emoticon can be inserted.
is this by design?
Reporter | ||
Comment 1•24 years ago
|
||
1) can't insert one right after another
2) can't insert at the start of the message (the first line, the first
character)
Summary: unable to insert two emoticons, one right after the other → unable to insert emoticons (two cases)
Assignee | ||
Comment 3•24 years ago
|
||
In the patch I insert the following source, if user chooses a smile from menu
(different codes for different types of course):
<span sml="s1"><span>:-)</span></span>
Together with CSS in EditorContent.css, it provides:
- background image instead of text code, that cannot be editable (just
insertion and delete are allowed);
- different views for the element: (a smiley) image in normal editor view and
text code in preview mode;
- elimination of all previous design restrictions concerned with place, where
smileys can be inserted (like collapsed selection and text node)
Assignee | ||
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
r=cmanske
Comment 6•24 years ago
|
||
There is one problem with this approach, which is that we might now conflict with
spans in user documents having a "sml" attribute. Should this be renamed to be
more explicitily mozilla-specific, like "-moz-smiley" ?
Assignee | ||
Comment 7•24 years ago
|
||
Sure, no problem, it is done.
Assignee | ||
Comment 8•24 years ago
|
||
Things work pretty well with the 02/19/01 15:31 patch.
Some suggestions to consider before checkin:
1. The editor calls in doCommand() should probably be wrapped with try/catch.
We've been having problems with uncaught exceptions killing the editor UI
so I just want to avoid that situation.
2. We can collapse alot of the similar -moz-smiley rules into a single rule
if we avoid checking for specific values, which could save you lots of
typing:
span[-moz-smiley] {
min-height: 17px; margin-left: 2px; margin-top: 2px;
padding-left: 20px;
background-repeat: no-repeat;
background-position: center center;
}
span[-moz-smiley] > span {
display: none;
}
span[-moz-smiley="s1"] {
background-image: url(chrome://editor/content/images/smile.gif);
}
span[-moz-smiley="s2"] {
background-image: url(chrome://editor/content/images/frown.gif);
}
...
sr=kin@netscape.com
Comment 10•24 years ago
|
||
fix checked in by syd on behalf of anatoliya@netscape.com
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 11•24 years ago
|
||
Seth, is this working for you now? can you mark this verified-fixed ? thanks!
Comment 12•24 years ago
|
||
can someone please verify this is fixed now? and mark verified-fixed...thanks.
Assignee | ||
Updated•24 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 13•24 years ago
|
||
Suzanne verified that today
You need to log in
before you can comment on or make changes to this bug.
Description
•