Closed Bug 56604 Opened 24 years ago Closed 23 years ago

caret navigation in TEXTAREAs always jumps to end-of-line when moving up or down.

Categories

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

Product:
Core
Component:
DOM: Editor
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: sgifford+mozilla-old, Assigned: rubydoo123)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; m18) Gecko/20001010
BuildID:    2000101021

When entering multiple lines of text in a TEXTAREA, moving up or down with the
keyboard always jumps to the end of line.

Reproducible: Always
Steps to Reproduce:
1. Visit a Web page with a TEXTAREA.

2. Enter multiple lines of text in this area.

3. Move the caret to the beginning of one of those lines, or any other point in
the middle.

4. Press the up or down arrow on the keyboard.

Actual Results:  Caret jumps to end of the previous of the line we just moved
to.

Expected Results:  Caret stays in the same character position as on the line
that we moved from.

I also see this in M17; haven't tried M18 yet.
This seems to be an off-by-one error from what I see.  I did this:
 * typed 4 lines of text ('this is a test')
 * moved caret to the beginning of all the text
 * pressed down arrow
   I now see the caret blinking *after* the first character although it should be 
*before* the first character as it was on the first line
 * arrowed to the right 5 times
 * pressed down arrow
   I now see the caret blinking after the 's' rather than between the 'i' and 's' 
as it was above

Notes:  I see the above behavior on Macintosh and my Linux branch builds; this 
does not seem to be the same behavior described by sgifford@tir.com

Because this is not crashing or causing dataloss; setting to Milestone Future for 
now.  (However, this is *REALLY* annoying and should be fixed soon!)

Joe--is this a duplicate of one of your existing bugs?
Target Milestone: --- → Future
FYI, I'm still seeing the same behavior (not what brade@netscape.com saw) on a
fresh build from CVS on 10/15/2000.


Confirmed linux 2000110206

Another thing that's probably connected with this:

1. Type enough text to fill the visible textarea (so it will scroll down).
2. Make sure the first line is short.
3. Scroll down to make sure the first line isn't visible anymore
4. Press end on a line that's longer than the first
5. Press up to scroll up.

It won't scroll up to the first line.. The steps may sound obscure but it
happens quite often.
Status: UNCONFIRMED → NEW
Ever confirmed: true
On the first testcase, I see what Kathy sees (off by one), not the end-of-line
that Scott sees (though both are wrong).  I'm guessing that it's dependant on
what sort of text is there.  On the second test case, I see what Scott sees:
doesn't scroll up.

Cc'ing Mike and Anthony for the selection, Kin for the scrolling.
The scrolling problem is already reported as  bug #48543, and only happens if
you place the caret in a position on a long line that is beyond the last char of
the first line.

I'm not exactly sure why that matters.

Bizarrely, I see brade@netscape.com's behavior on this page (the standard bug
editing page), but I see the "jump to end of line" behavior I was seeing before
on the Bugzilla Helper page, at

	http://www.mozilla.org/quality/help/bugzilla-helper.html


correct summary to use "caret"
Summary: Cursor navigation in TEXTAREAs always jumps to end-of-line when moving up or down. → caret navigation in TEXTAREAs always jumps to end-of-line when moving up or down.
Has this been fixed?  Can anyone reproduce this bug?  Is this Linux-specific?  
What text is used to reproduce?  Do you press return/enter at the end of each 
line or not at all or ?

I no longer see this bug on 2001032614.

great, marking wfm
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified in 4/3 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.