Blank paragraphs not always deleted




16 years ago
15 years ago


(Reporter:, Assigned: Joe Francis)


Windows 95

Firefox Tracking Flags

(Not tracked)


(Whiteboard: EDITORBASE+ [adt2] fixinhand; patch in 129763)


(1 attachment)



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

16 years ago
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<>
Assignee: kin → jfrancis
Whiteboard: EDITORBASE

Comment 2

16 years ago
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.
Summary: Blank preformmatted paragraphs not always deleted → Blank paragraphs not always deleted

Comment 3

16 years ago
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.
Keywords: nsbeta1+
Target Milestone: --- → mozilla1.0

Comment 4

16 years ago
pri = 2 for original 1.0 EB+ bugs
Priority: -- → P2
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.
getting ownership of this bug 
Assignee: jfrancis → glazman

Comment 8

16 years ago
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?


16 years ago
Whiteboard: EDITORBASE+ → EDITORBASE+ [adt2]

Comment 9

16 years ago
assigning to me at daniels request
Assignee: glazman → jfrancis

Comment 10

16 years ago
The patch in 129763 fixes this.
Whiteboard: EDITORBASE+ [adt2] → EDITORBASE+ [adt2] fixinhand; patch in 129763

Comment 11

16 years ago
*** Bug 149838 has been marked as a duplicate of this bug. ***
nsbeta1-. The fix is too risky for the 1.0 branch.
Keywords: nsbeta1+ → nsbeta1-

Comment 13

16 years ago
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.
Target Milestone: mozilla1.0 → mozilla1.2beta


16 years ago
Target Milestone: mozilla1.2beta → M1


16 years ago
Keywords: nsbeta1- → nsbeta1
Target Milestone: M1 → mozilla1.2alpha

Comment 14

16 years ago
fix landed on trunk
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 15

16 years ago
hmm, not seeing fix working on latest trunk bits.  investigating...
Resolution: FIXED → ---


16 years ago
Target Milestone: mozilla1.2alpha → M1

Comment 16

16 years ago
ok, fixed with revised landing of 129763
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
QA Contact: sujay → sairuh
looks fixed --tested with 2003.03.03 on win2k.
You need to log in before you can comment on or make changes to this bug.