Closed
Bug 103677
Opened 23 years ago
Closed 23 years ago
Empty Heading tags are left after deleting the text on that line
Categories
(Core :: DOM: Editor, defect, P2)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: TucsonTester2, Assigned: mozeditor)
Details
(Whiteboard: EDITORBASE+; FIXINHAND; need r=)
Attachments
(1 file, 1 obsolete file)
3.64 KB,
patch
|
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
Build ID: 20011004 Composer leaves an empty heading tag and a line you can not access if you delete the heading using the backspace key without first selecting the line. This only happens if the heading is between text with a different paragraph style. Reproducible: Always Steps to Reproduce: 1.Open Composer 2.Type some text and hit enter 3.Choose "Heading 1" from the paragraph style drop-down menu on the toolbar 4.Type in some text and hit enter 5.Type some more text 6.Place the cursor back on the line with the heading 1 style 7.Backspace the contents till the cursor jumps to the end of the first line 8.Switch to "Show All Tags" view Actual Results: When you switch to show all tags view you will see that there is still a heading 1 tag on the line. Now if you switch back to normal view and try placing your cursor on the heading 1 line you will see that it is impossible. Expected Results: I would expect that deleting the line with heading 1 paragraph style would also remove the <h1> tag. I would also expect that if the tag did not get deleted that the line would be accessible.
Modification to step 6 -- put cursor at end of line. The intent is to delete all of the characters on that line.
Assignee: syd → cmanske
Whiteboard: EDITORBASE
Comment 2•23 years ago
|
||
editor core
Assignee: cmanske → jfrancis
Component: Editor: Composer → Editor: Core
Comment 3•23 years ago
|
||
Confirming Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011113
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 4•23 years ago
|
||
I beleive the behavior we want is for the last character deletion to leave the H1, bt for it to of course be clickable. Then if you backspace one more time the H1 should go away.
Status: NEW → ASSIGNED
Whiteboard: EDITORBASE → EDITORBASE; 1 day
Target Milestone: --- → mozilla0.9.7
also, using cut from the edit menu will not remove the H1.
Priority: -- → P2
Comment 7•23 years ago
|
||
I don't think that a majority of our users will run into this very often so I would recommend pushing this bug off EDITORBASE entirely or pushing it off until after mozilla 1.0 milestone.
Assignee | ||
Comment 8•23 years ago
|
||
pushing off 098 to 099
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 9•23 years ago
|
||
marking EDITORBASE+ per meeting
Whiteboard: EDITORBASE; 1 day → EDITORBASE+; 1 day
Assignee | ||
Comment 10•23 years ago
|
||
THIS PATCH WILL NOT APPLY - FOR REVIEW PURPOSES ONLY Line numbers are wrong because I have other changes in the file... I moved some code in AdjustSelection() so that we always populate an empty block with a br if the selection is inside it. Before we did it only sometimes. note that this also fixes bug 99545.
Assignee | ||
Updated•23 years ago
|
Whiteboard: EDITORBASE+; 1 day → EDITORBASE+; FIXINHAND; need r=, sr=
Assignee | ||
Comment 11•23 years ago
|
||
Even better than the first patch! Act now before they are all gone! Operators are standing by...
Attachment #68854 -
Attachment is obsolete: true
Comment 12•23 years ago
|
||
Comment on attachment 69039 [details] [diff] [review] patch to nsHTMLEditRules.cpp rev 2 sr=kin@netscape.com Do we also need to handle the case where we have the caret (|) directly in an empty block contained in a bloc? Something like this: <div>text<div>|</div>text</div> I ask cause I think the existing code always starts looking at the selnode's parent.
Attachment #69039 -
Flags: superreview+
Whiteboard: EDITORBASE+; FIXINHAND; need r=, sr= → EDITORBASE+; FIXINHAND; need r=
Assignee | ||
Comment 13•23 years ago
|
||
fixed on tip
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•