73110 - Selection left in wrong place after dragging text

Status: RESOLVED WORKSFORME

(Core :: DOM: Selection, defect, P4)

Description

[sujay]

using 3/22 build of netscape

1) launch netscape
2) launch composer
3) enter some text on several lines 
4) leaving caret at the end of the last line 
5) drag all the text from first line to end of line

caret jumps to next line 

caret should remain at end of last line.

Comment 1

[Kathleen :Brade]

If I drag text, I expect the caret to be at the end of the dragged text or for 
the dragged text to be entirely selected.  I see this in my debug Mac mozilla 
build from today.

Sujay--any idea when this broke?

Comment 2

[rubydoo123]

I think I am reproducing the steps
1. are you hitting enter at the end of the line or letting it wrap?
2. are you pressing enter after the last line? if not, how can the caret jump to 
the next line?
3. when you drag from the beginning to the end are you stopping to the left of 
the blinking caret or are you dragging past the caret?

on win98 using the build from 2001032904 I cannot reproduce this

Comment 3

[sujay]

This problem has disappeared....Kathy can you still reproduce it?

Comment 4

[Kathleen :Brade]

I still see the caret going to the wrong place (Mac debug build from today).

Comment 5

[rubydoo123]

moz1.0

Comment 6

[Syd Logan]

spam composer change

Comment 7

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 8

[Kathleen :Brade]

What I see in Netscape 7 build is this:
  * enter this text into composer
       abc
       def
       ghi
  * click after 'f'
  * double click "abc"
  * drag selection to after 'i'
Result is caret blinks before ghi

If you skip the step for clicking after 'f', the caret blinks on the blank line
where "abc" used to be.

Comment 9

[Kathleen :Brade]

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

Comment 10

[Simon Fraser [no longer active]]

Still an issue. On drop, we should leave the dropped text selected. What happens
now is that the selection is left where it was before you dragged, and is now
collapsed.

Comment 11

[Kevin McCluskey (gone)]

I can not reproduce using 2003031905 build on WinXP.

editorbase+, nsbeta1+ for Mac work.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

In these days, we hide caret while there is a non-collapsed selection range.
https://searchfox.org/mozilla-central/search?q=symbol:E_%3CT_mozilla%3A%3ALookAndFeel%3A%3AIntID%3E_ShowCaretDuringSelection&redirect=false

Therefore, we can reproduce this anymore.