41525 - (editor/textarea) Select text, press up/down should go up/down from final insertion point

Status: VERIFIED FIXED

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

Description

[Jesse Ruderman]

If you select text in a textarea or in editor and then press up or down, the 
insertion point should end up strait up or down from the final insertion point 
(if you selected using the mouse, this is where you let go of the mouse 
button).  Mozilla currently treats up as left and down as right.

IE5 does this completely incorrectly, by moving several spaces left in addition 
to switching lines.  IMO mozilla should copy notepad's behavior here.

Comment 1

[Jesse Ruderman]

Attachment: html with textarea for demonstrating bug

Comment 2

[rubydoo123]

setting to m17 and assigning to mjudge

Comment 3

[Kathleen :Brade]

Interesting...

On Macintosh, the expected behavior is to go to the beginning of the selection 
with an up arrow press (removing the selection highlighting) and to remove the 
selection highlighting and go to the end fo the selection with a down arrow 
press.

In Composer, today's build works this way.  I don't think we should change the 
behavior.

Comment 4

[mjudge]

no for text areas there are some rounding issues with the text area indention. 
anthony will look into this.

Comment 5

[mjudge]

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

Comment 6

[rubydoo123]

setting to nsbeta3+

Comment 7

[rubydoo123]

setting priority in status whiteboard

Comment 8

[anthonyd]

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

Comment 9

[Jesse Ruderman]

It seems to me that there are two issues here:
- when text is selected, up/down has different expected results on different 
platforms, and mozilla follows the mac standard (this bug, polish designation)
- cursor drift (the bugs marked as dups, and probably the nsbeta3+ designation)

Antonhyd, is the same thing causing both problems?

Comment 10

[anthonyd]

ok, this IS working correctly (by correctly I mean the text fields behave the 
same way as composer) IF you use the mouse to handle the selection, and THEN 
press an arrow key.  If you use the arrow keys to create the selection 
(shift+arrow) then ytou still have problems, but apparently there are several 
problems with arrow key bindings as is right now.

Does anyone know what the bug is for scrolling with arrow keys in text fields?

Comment 11

[rubydoo123]

anthony fixed this, marking as such so QA can test

Comment 12

[Koike Kazuhiko]

The problem still remains with Linux 2000091108. Nothing changed.

Comment 13

[sujay]

verified in 9/12 build.

Comment 14

[Jesse Ruderman]

The original problem in this bug wasn't fixed.  The problems marked as dups of 
this bug weren't fixed.  Why is this bug marked as fixed?

Comment 15

[anthonyd]

this bug is amrked as fixed because it works as intended.  The behaviour is 
expected, and consistent across all platforms.

Anthony

Comment 16

[Koike Kazuhiko]

I agreed width Jesse Ruderman. This bug and bug 51136 wasn't fixed
in Linux 2000091312. Were these bug INVALID?

Comment 17

[anthonyd]

I reopened 51136 because that is a different bug.  But this bug isnt going to 
change unless some higher power decrees it.  This works as intended.

anthonyd

Comment 18

[Jesse Ruderman]

reopening to mark as wontfix.

Comment 19

[anthonyd]

marking bug as fixed.

anthonyd

Comment 20

[anthonyd]

we are open to suggestions on improving caret movement when dealing with 
selections, if you want this bug to be open, we need something more to go on.  

the fact that the behavior isnt liked (is that a good word here?), especially on 
a platform like unix where no desktop is the same, is hard to satisfy.  in 
seamonkey right now, the cursor behavior with selections is well defined, and 
very predictable on all platforms (ie. it is the same on mac as windows as 
unix/linux).

I dont want anyone to get angry or frustrated on this, but we have to move on 
without more concrete information.

anthony

Comment 21

[sujay]

marking verified again.