164060 - Drop link into list item makes cursor jump to next item

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Akkana Peck]

This is a regression from moz 1.0 in writing my status reports:

Start a list item, then drag a link from a browser window to the end of the list
item line in composer.  After the drop, type a few words.

In 1.0, after the link drop, the caret is positioned after the link, but outside
it: the new words typed are not in the link.  This makes it very easy to drag a
bug link then type some text about what the bug is about or what I've done on it
this week, or even a period to end the sentence.

In the trunk, starting immediately after the 1.0 branch, when the link is
dropped, the caret jumps to the next line (the next list item if there is one,
otherwise completely outside the list); if I do backarrow or click at the end of
the list to place the caret where it ought to be, the caret is now inside the
link, so I have to do (the undiscoverable) Discontinue Link in order to type any
comments about the bug.

So this is two issues:
(1) After a drop the caret should be positioned after the drop but outside it.
(2) Setting the caret to the end of a line that ends with a link should put the
caret outside the link, not inside it.  (There may already be another bug
tracking this; I know there was once, but it may have been fixed and then
regressed.)

Comment 1

[Akkana Peck]

EDITORBASE+ per discussion at editor meeting.

Comment 2

[Joe Francis]

Attachment: patch to nsHTMLEditRules.cpp

more forgiving selection tweaking.  Allow selection to be "next to" a text node
as well as inside one.

Comment 3

[Joe Francis]

note to self: fix ws alignment in the diff

Comment 4

[kinmoz]

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

sr=[e-mail]

Just fix the indentation problems you mentioned above.

I'm assuming there is a reason why we don't have to adjust the selection in the
case when we find a prior/next text node?

Comment 5

[kinmoz]

Duh, forget about my question above.

Comment 6

[Joe Francis]

fixed on trunk

Comment 7

[sairuh (rarely reading bugmail)]

for the most part, this bug is fixed (tested with 3/3 bits on win2k and linux,
2/28 bits on mac).

found an issue with d'n'd of links, but i'll verify this. the new issue is bug
195811.