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
•