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

VERIFIED WORKSFORME

Status

()

P3
normal
VERIFIED WORKSFORME
18 years ago
18 years ago

People

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

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 1

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

Comment 2

18 years ago
FYI, I'm still seeing the same behavior (not what brade@netscape.com saw) on a
fresh build from CVS on 10/15/2000.

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

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

Comment 7

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

Comment 8

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

Comment 9

18 years ago
I no longer see this bug on 2001032614.
(Assignee)

Comment 10

18 years ago
great, marking wfm
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 11

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