Closed
Bug 208317
Opened 22 years ago
Closed 22 years ago
Caret can disappear in css-enabled html editor
Categories
(Core :: DOM: Editor, defect, P1)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
mozilla1.4final
People
(Reporter: mozeditor, Assigned: mozeditor)
References
Details
(Keywords: topembed+, Whiteboard: [vrfy'd on mac/win32 branch, mac trunk])
Attachments
(1 file)
1.48 KB,
patch
|
Brade
:
review+
kinmoz
:
superreview+
asa
:
approval1.4+
|
Details | Diff | Splinter Review |
steps:
open a new composer window
make bold
type "x"
hit backspace
results: caret disappears
The real problem is that the span used to make bold (via font-weight attribute)
is not removed when the "x" is deleted. In general the editor removes inline
elements when they become empty. In non-css mode this bug doesn't occur, the
<b> tag used there is removed.
Comment 1•22 years ago
|
||
Marking nsbeta1+, topembed+ since it blocks bug 14037 which is already
nsbeta1+, topembed+
Updated•22 years ago
|
Priority: -- → P1
Target Milestone: --- → mozilla1.4final
Assignee | ||
Comment 2•22 years ago
|
||
one line fix, adding span tags to the list of tags we delete if empty.
Assignee | ||
Updated•22 years ago
|
Attachment #125216 -
Flags: superreview?(kin)
Attachment #125216 -
Flags: review?(brade)
Updated•22 years ago
|
Attachment #125216 -
Flags: review?(brade) → review+
Comment on attachment 125216 [details] [diff] [review]
patch to nsHTMLEditRules.cpp
sr=kin@netscape.com
I think the caret disappearing when in empty inlines might actually be related
to bug 202046.
Attachment #125216 -
Flags: superreview?(kin) → superreview+
Assignee | ||
Comment 4•22 years ago
|
||
Comment on attachment 125216 [details] [diff] [review]
patch to nsHTMLEditRules.cpp
requesting approval. this blocks 140357, which is a stopper for one of our 1.4
based embedders.
Attachment #125216 -
Flags: approval1.4?
Comment 5•22 years ago
|
||
Comment on attachment 125216 [details] [diff] [review]
patch to nsHTMLEditRules.cpp
a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #125216 -
Flags: approval1.4? → approval1.4+
Comment 6•22 years ago
|
||
a=adt to land this on the 1.4 branch since this bug blocks adt-approved bug
140357. Please add the fixed1.4 keyword once you have landed this. Thanks.
Assignee | ||
Comment 7•22 years ago
|
||
fix landed on trunk. revision:
1.287 mozilla/editor/libeditor/html/nsHTMLEditRules.cpp
This revision also includes 140357 changes.
Assignee | ||
Comment 8•22 years ago
|
||
fix landed on 1.4 branch as art of 140357 landing. See that bug for revisions.
Assignee | ||
Comment 9•22 years ago
|
||
marking fixed since this has landed everywhere.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 10•22 years ago
|
||
Sarah, I think this bug is fixed.
Trunk and Branch build 2003-06-12: Win2k, Mac 10.1.5
In older builds I was not able to reproduce the problem with the caret
disappearing but I did observe the problems in the HTML Source where '<span
style="font-weight: bold;">test</span>" was not removed when the bold text was
removed.
Now with the latest build (6/12) the problem appears fixed. With the "Use CSS
Styles instead of HTML elements and attributes" pref selected:
** 6/12 with bold text present **
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<title></title>
</head>
<body>
<span style="font-weight: bold;">test</span>
</body>
</html>
** 6/12 after bold text is removed **
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<title></title>
</head>
<body>
<br>
</body>
</html>
In addition I deselected the pref to use CSS Styles and it behaves in a similar
fashion where the <b> tag is removed when the bold text is removed and reappears
if bold text is present.
Comment 11•22 years ago
|
||
i'll check this now with Mac OS X 10.2.6 branch bits (linux branch will have to
wait a bit due to the build stuff there).
Comment 12•22 years ago
|
||
yes, this looks fine on OS X, 10.2.6. tested both branch (2003.06.13.05-1.4) and
trunk (2003.06.13.08-trunk) comm builds.
Ninoschka, thanks for checking this with the branch bits on win2k.
as mentioned before, i'll need to check linux later on.
Whiteboard: [vrfy'd on mac/win32 branch, mac trunk]
Comment 13•22 years ago
|
||
vrfy'd fixed with 2003.06.17.11-1.4 comm branch bits on linux rh8.0.
Keywords: fixed1.4 → verified1.4
You need to log in
before you can comment on or make changes to this bug.
Description
•