Caret can disappear in css-enabled html editor

RESOLVED FIXED in mozilla1.4final

Status

()

Core
Editor
P1
critical
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: Joe Francis, Assigned: Joe Francis)

Tracking

({topembed+})

Trunk
mozilla1.4final
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [vrfy'd on mac/win32 branch, mac trunk])

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
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.
(Assignee)

Updated

15 years ago
No longer blocks: 140357
(Assignee)

Updated

15 years ago
Blocks: 140357
Marking  nsbeta1+, topembed+ since it blocks bug 14037 which is already
nsbeta1+, topembed+
Keywords: nsbeta1+, topembed+

Updated

15 years ago
Priority: -- → P1
Target Milestone: --- → mozilla1.4final
(Assignee)

Comment 2

15 years ago
Created attachment 125216 [details] [diff] [review]
patch to nsHTMLEditRules.cpp

one line fix, adding span tags to the list of tags we delete if empty.
(Assignee)

Updated

15 years ago
Attachment #125216 - Flags: superreview?(kin)
Attachment #125216 - Flags: review?(brade)

Updated

15 years ago
Attachment #125216 - Flags: review?(brade) → review+

Comment 3

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

15 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

15 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

15 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

15 years ago
fix landed on trunk. revision:
1.287 mozilla/editor/libeditor/html/nsHTMLEditRules.cpp

This revision also includes 140357 changes.
(Assignee)

Comment 8

15 years ago
fix landed on 1.4 branch as art of 140357 landing.  See that bug for revisions.
(Assignee)

Comment 9

15 years ago
marking fixed since this has landed everywhere.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Updated

15 years ago
Keywords: fixed1.4

Comment 10

15 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. 
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).
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]
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.