169033 - Additional content removed when deleting a <LI>

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Kevin McCluskey (gone)]

Using 2002091608 trunk build on WINNT.

1. Load the attachment into composer
2. Click at the end of the text "line4"
3. Keep hitting the backspace key to delete each character of line4.
4. Continue hitting the backspace key.

After the <LI> for line4 is removed other content above line4 is also removed

Comment 1

[Kevin McCluskey (gone)]

Attachment: HTML file to edit

Comment 2

[Joe Francis]

I am unable to reproduce the bug described, though I do see another proble: the
various UL nodes are not deleted as you backspace through them, which has no
visible ramifications but which is still incorrect.

Comment 3

[Syd Logan]

I'm seeing this too when I edit status reports. Plussing.

Comment 4

[Joe Francis]

Attachment: patch to nsHTMLEditRules.cpp

Two part fix:

1) CheckForEmptyBlock() now continues looking up from the current selection for
as long as we are in (nested) empty blocks.  Thus when you delete the last <li>
in a <ol>, the <ol> is also deleted, etc.

2) The code in CheckForEmptyBlock() that detected deletion of the first <li>
and gave us a br (to create an empty line) has been modified to only do this if
the <li> was not a sublist.  In other words, only if there is aplace to create
a <br> that is _outside_ of a list.

Comment 5

[kinmoz]

Comment on attachment 101501 [details] [diff] [review]
patch to nsHTMLEditRules.cpp

Is there code that gets executed after CheckForEmptyBlock() that will prevent
the caret from ending up in the list body itself? The cases I'm thinking of are
something like:

  body text
    o Outer list
      o |
      o Inner List Item 2
      o Inner List Item 3


or:


  body text
    o Outer list
      o Inner List Item 1
      o |
      o Inner List Item 3

Comment 6

[Joe Francis]

There is no such code but I am aware of the issue.  There are other ways this 
could happen (such as pasting in an entire <li>) so I want to have the selection 
adjustment for this happen at AfterEdit() time.  There is already an open bug on 
this (#152304) and I am working on it now.

Comment 7

[kinmoz]

Comment on attachment 101501 [details] [diff] [review]
patch to nsHTMLEditRules.cpp

sr=[e-mail]

Comment 8

[Joe Francis]

fixed on trunk

Comment 9

[sairuh (rarely reading bugmail)]

looks fixed --tested with 2003.02.19 on win2k.