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

VERIFIED FIXED in M18

Status

()

Core
Editor
P3
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Jesse Ruderman, Assigned: anthonyd)

Tracking

({polish})

Trunk
x86
Windows 98
polish
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][p:3])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 9613 [details]
html with textarea for demonstrating bug

Comment 2

18 years ago
setting to m17 and assigning to mjudge
Assignee: beppe → mjudge
Target Milestone: --- → M17

Comment 3

18 years ago
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

18 years ago
no for text areas there are some rounding issues with the text area indention. 
anthony will look into this.
Assignee: mjudge → anthonyd
Keywords: correctness, nsbeta3
Target Milestone: M17 → M18

Comment 5

18 years ago
*** Bug 42310 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 6

18 years ago
setting to nsbeta3+
Whiteboard: nsbeta3+

Updated

18 years ago
Whiteboard: nsbeta3+ → [nsbeta3+][p:3]

Comment 7

18 years ago
setting priority in status whiteboard
(Assignee)

Updated

18 years ago
Keywords: polish
(Assignee)

Comment 8

18 years ago
*** Bug 51136 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 9

18 years ago
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?
(Assignee)

Comment 10

18 years ago
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

18 years ago
anthony fixed this, marking as such so QA can test
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 12

18 years ago
The problem still remains with Linux 2000091108. Nothing changed.

Comment 13

18 years ago
verified in 9/12 build.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 14

18 years ago
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?
(Assignee)

Comment 15

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

Anthony

Comment 16

18 years ago
I agreed width Jesse Ruderman. This bug and bug 51136 wasn't fixed
in Linux 2000091312. Were these bug INVALID?
(Assignee)

Comment 17

18 years ago
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
(Reporter)

Comment 18

18 years ago
reopening to mark as wontfix.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 19

18 years ago
marking bug as fixed.

anthonyd
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 20

18 years ago
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

18 years ago
marking verified again.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.