127235 - Blank paragraphs not always deleted

Status: VERIFIED FIXED

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

Description

[[e-mail]]

Using Build ID: 2002022103
Steps to reproduce problem:
1. Open an HTML editor (I see this most with message compose, but editor will do)
2. Insert three lines of text.
3. Position the cursor at the start of the second line.
4. Change the second line to preformatted.
5. Press Shift+Down so the whole of the second line is highlighted.
6. Press Del.

Expected results: entire second line deleted

Actual results: only contents are deleted, the line itself is now undeletable.

Additional information:
You can also do the selection the other way around, and you can also select
additional text on the third line, and the problem will still appear.

Comment 1

[kinmoz]

Interesting, backspace works fine, it deletes the <pre> content, adds a <br> to 
the <pre> and leaves the caret in the <pre>. Here's the content tree:


==============  Content Tree: ================
body@04A20BD0 refcount=35<
  Text@04E7E008 refcount=71<Line 1>
  br@046BD5D0 _moz_dirty="" refcount=4<>
  pre@04BCC080 _moz_dirty="" refcount=15<
    br@04BDF8B0 _moz_dirty="" type="_moz" refcount=5<>
  >
  Text@04C3B8B0 refcount=35<Line 3>
  br@04BB1690 _moz_dirty="" type="_moz" refcount=8<>
  br@04A61678 _moz_editor_bogus_node="TRUE" _moz_dirty="" refcount=5<>
>


In the case of forward delete, the caret appears to be at the beginning of the 
3rd line after the delete ... not sure if it really is positioned there or if 
it's just the caret code compensating for the lack of anything inside the <pre> 
to attatch to. The <pre> actually contains an empty text node after the 
operation. Here's what the content looks like in this case:


==============  Content Tree: ================
body@04A20BD0 refcount=35<
  Text@04E7E008 refcount=71<Line 1>
  br@046BD5D0 _moz_dirty="" refcount=4<>
  pre@04BCC080 _moz_dirty="" refcount=5<
    Text@04F1BF68 refcount=44<>
  >
  Text@04C3B8B0 refcount=41<Line 3>
  br@04BB1690 _moz_dirty="" type="_moz" refcount=8<>
  br@04A61678 _moz_editor_bogus_node="TRUE" _moz_dirty="" refcount=5<>
>

Comment 2

[[e-mail]]

You can reproduce this with backspace as well, but you have to select from the
first line to the end of the second line.

You can reproduce this with any paragraph style but preformat is the most obvious.

Comment 3

[Syd Logan]

Why aren't we deleting the PRE once the content is gone? Is this a caret
problem, a selection problem? Should we always make sure pre's have a br in them
at a minimum? Joe, we have some other issues like this where we delete the last
thing inside of formatting and leave the formatting. Seems like there is a
general solution possible in the rules code.

Comment 4

[Joe Francis]

pri = 2 for original 1.0 EB+ bugs

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I think I see where the problem comes from in the code. It's both a selection and
parent removal problem. We collapse the selection immediately _after_ the text
removed but we have some code looking at empty text nodes to remove them. In the
text case above, the empty text node is before the final collapsed selection.

Comment 6

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: patch v1.0

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

getting ownership of this bug 

Comment 8

[Joe Francis]

I think this may not work.  I can't easily apply the patch right now so I'm not 
completely sure, but here is what I'm worried about:

In the case where we backspace through a paragraph one character at a time, for 
instance, when we eliminate the last character, we don't yet delete the 
paragraph.  We delete the paragraph if you hit backspace one more time, after 
deleting the last character.  

Doing the same thing deleting forward through a paragraph should behave 
similarly.  But I think with this patch, once you delete the last character, the 
whole paragraph will dissappear as well.  Daniel, can you test this?

Comment 9

[Joe Francis]

assigning to me at daniels request

Comment 10

[Joe Francis]

The patch in 129763 fixes this.

Comment 11

[[e-mail]]

*** Bug 149838 has been marked as a duplicate of this bug. ***

Comment 12

[Kevin McCluskey (gone)]

nsbeta1-. The fix is too risky for the 1.0 branch.

Comment 13

[Joe Francis]

The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.

Comment 14

[Joe Francis]

fix landed on trunk

Comment 15

[Joe Francis]

hmm, not seeing fix working on latest trunk bits.  investigating...

Comment 16

[Joe Francis]

ok, fixed with revised landing of 129763

Comment 17

[sairuh (rarely reading bugmail)]

looks fixed --tested with 2003.03.03 on win2k.