103677 - Empty Heading tags are left after deleting the text on that line

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P2)

Description

[TucsonTester2]

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.

Comment 1

[Syd Logan]

Modification to step 6 -- put cursor at end of line. The intent is to delete all
of the characters on that line.

Comment 2

[Charles Manske]

editor core

Comment 3

[Alex Vincent [:WeirdAl]]

Confirming Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011113

Comment 4

[Joe Francis]

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.

Comment 5

[Joe Francis]

098

Comment 6

[Syd Logan]

also, using cut from the edit menu will not remove the H1.

Comment 7

[Kathleen :Brade]

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.

Comment 8

[Joe Francis]

pushing off 098 to 099

Comment 9

[Kathleen :Brade]

marking EDITORBASE+ per meeting

Comment 10

[Joe Francis]

Attachment: patch to nsHTMLEditRules.cpp

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.

Comment 11

[Joe Francis]

Attachment: patch to nsHTMLEditRules.cpp rev 2

Even better than the first patch!  Act now before they are all gone!  Operators
are standing by...

Comment 12

[kinmoz]

Comment on attachment 69039 [details] [diff] [review]
patch to nsHTMLEditRules.cpp rev 2

sr=[e-mail]

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.

Comment 13

[Joe Francis]

fixed on tip

Comment 14

[michael wendell]

Verified on Win XP using build 02-20.