170547 - Caret is in the wrong place after deleting <LI>'s

Status: VERIFIED FIXED

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

Description

[Kevin McCluskey (gone)]

1. click on bold
2. enter the text "this is a test"
3. click on <LI>
4. enter item1 for the first <LI>
5. hit return
6. enter item2 for the second <LI>
7. select both item1 and item2 by dragging from item2 to item1
8. Hit backspace to delete
9. Hit another backspace. It Appears to do nothing. Caret stays at the same
location. 
(I Would expect the caret to jump to the end of "this is a test"
10. Hit another backspace It deletes the "t" in "this is a test".
(I would have expected the caret to just jump to the previous line since it was
on the next line below "this is a test"


This seems like a caret placement issue. Step 9 probably moved the caret but it
did not visually update the caret position. So when I hit the backspace a second
time it jumps one line up and deletes the "t" unexpectedly.

Comment 1

[Kevin McCluskey (gone)]

nominating for EDITORBASE. This is a very common editing operation. 

Comment 2

[Jim Booth]

Attachment: Test case showing similar problem. Caret jumps to top of document.

In a possibly-related problem, deleting JUST the closing tag at the end of a
line in Normal view causes the caret to jump to the top of the document. 
Release 2002102908 in Windows ME.   APPLIES TO BOTH COMPOSER AND MAIL COMPOSE

Applies to </p>, </li>, </h1> thru </h6> and others when another line of the
same type immediately follows.	Place caret at end of line and hit DELETE.  The
closing tag and following open tag (</p>, newline and <p>, for example) ARE
deleted as expected, but the caret jumps to the top of the document.

(Could be limited to Windows because newlines are CR/LF not just LF)

Comment 3

[Kevin McCluskey (gone)]

editorbase+, nsbeta1+
-> Joe

Comment 4

[Joe Francis]

WFM in my current tree which has a variety of unchecked-in patches.  I'll
revisit once i land the other work.

Comment 5

[Joe Francis]

nevermind, i see this problem with slightly different steps.  instead of drag
selecting the whole list, I get the problem if I backspace through the list a
char at a time.

Comment 6

[Joe Francis]

I filed Jim booth's bug (see comment #2) as bug 179384, becasue it is unrelated
to this bug.

Meanwhile, this bug is actually a layout bug.  Simple testcase:
1) new editor window
2) bold
3) type "xxx"
4) hit return
5) make list
6) hit backspace once (empty list disappears as expected)
7) hit backspace again (seeminly nothing happened)

If you examine the content model after step 7, you will see that the editor did
indeed delete a br, leaving only the one br at the end of "xxx".  This is
correct.  There should only be one linebox now, but the caret is drawing on a
second line.  Since the caret requires a frame to draw, this is evidence of a
dangling frame in layout.

Over to Kin for disposition.

Comment 7

[Joe Francis]

Another way to see that this is a layout issue is to take the resulting source
from my steps, create a new edit window, go to source view, and paste it in.
then go back to normal.  There is no blank line to click on.  So that blank line
is in the testcase is an artifact from layout.

Clearing milestone for Kin.

Comment 8

[Kevin McCluskey (gone)]

Giving it a milestone to get it off the bug triage radar.

Comment 9

[Simon Montagu :smontagu]

Attachment: Patch v.0

kin, this looks similar to the case you fixed in bug 102615, except that here
there is no next-in-flow. 

A final patch will have to modify the preceding comments as well, of course.

Comment 10

[Simon Montagu :smontagu]

Taking

Comment 11

[Simon Montagu :smontagu]

Attachment: patch v.1

I was hoping for some feedback, but I'll just request review with the comment
updated.

Comment 12

[kinmoz]

Comment on attachment 121323 [details] [diff] [review]
patch v.1

sr=[e-mail]


==== I'd remove the reference to nextInFlow from the comment and perhaps say
something like:


+    // If the frame we are removing is a brFrame, we need a reflow so
+    // the line the brFrame was on can attempt to pull up any frames
+    // that can fit from lines below it.


I don't think we need to mention the specific caret drawing case, since it is
the same "pull up" problem, but it's up to you.

Note that we really don't need to reflow if the br is at the end of the block,
but optimizing for that case would involve walking up the parent hierarchy
looking at next-in-flows and next-siblings ... I don't think we need to do
this, but I thought I'd mention it anyways.

Comment 13

[Simon Montagu :smontagu]

Fix was checked in a few days ago.

Comment 14

[sairuh (rarely reading bugmail)]

vrfy'd fixed following the tests in comment 0, comment 6 and comment 7. tested
with 2003.05.13 comm builds on the 3 main platforms.