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.
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
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
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.
Whiteboard: EDITORBASE → EDITORBASE+
Target Milestone: --- → mozilla1.0
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
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?
assigning to me at daniels request
Assignee: glazman → jfrancis
The patch in 129763 fixes this.
Status: NEW → ASSIGNED
Whiteboard: EDITORBASE+ [adt2] → EDITORBASE+ [adt2] fixinhand; patch in 129763
*** 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-
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
Keywords: nsbeta1- → nsbeta1
Target Milestone: M1 → mozilla1.2alpha
fix landed on trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
hmm, not seeing fix working on latest trunk bits. investigating...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
ok, fixed with revised landing of 129763
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
looks fixed --tested with 2003.03.03 on win2k.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.