left and right arrow keys in a textarea don't move cursor properly on very long lines

RESOLVED WORKSFORME

Status

()

Core
Selection
--
minor
RESOLVED WORKSFORME
16 years ago
10 years ago

People

(Reporter: Stewart, Assigned: mjudge)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021206
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021206

In any textarea (a multi-line text edit box), including the one used by the mail
composer, the left and right arrow keys no longer work as expected once beyond
the first displayed line of a very long line.  Frequently, the left arrow moves
the cursor to the end of the previous line and the right arrow moves the cursor
to the beginning of the next line, regardless of how many characters are between
the current cursor position and the position the cursor ends up at.  Positioning
the cursor with the mouse works as expected, and the up and down arrow keys also
work properly.

Reproducible: Always

Steps to Reproduce:
On any web page with a multi-line text area:
1. Click on the text area to place the selection cursor in it.
2. Type.  Keep typing until the browser wraps the current line into the next
one.  (Alternatively, you can paste this text into the field, or it can be there
in the first place.)  At this point, the problem with the left arrow shows up.
3. Press the left arrow.  The cursor has moved more than one character to the left.
4. Continue using the left arrow if desired.  In the first line (as displayed),
the arrow keys function normally.
5. If desired, try to use the right arrow to reach the end of the line. 
Clicking is easier.
6. If more text is typed in, to the point that another (displayed) line in the
line is complete, use the right and left arrow keys.
Actual Results:  
When the left arrow key is used, the cursor (usually) moves to the end of the
previous line (as displayed).  Although I don't understand why, it will
sometimes move to some other position in the current line instead, though rarely
to where it should go, but always to the left.
When the right arrow key is used, the cursor (usually) moves to the beginning of
the next line (as displayed).  Again, it will sometimes move to some other
position in the current line instead, although always to the right.  At the
beginning of the second (displayed) line of a long line, I have also observed
the right arrow key functioning normally on occassion, sometimes for several
characters.

Expected Results:  
The insertion point, as indicated by the cursor, should move left one character
for each press of the left arrow key, and right one character for each press of
the right arrow key.

The theme in use seems to make no difference.
Mozilla was compiled from source.  GCC 2.95.3 and libc 2.1.2 are installed.
selection
Assignee: form → mjudge
Component: Layout: Form Controls → Selection
QA Contact: tpreston → pmac

Comment 2

15 years ago
I'm using build ID 20030226 for linux. Just playing around with this "additional
comments" field, I can't reproduce this.

Sandreas, can you reproduce this with a current copy of mozilla?
(Reporter)

Comment 3

15 years ago
Seems to work now, as of Mar.02 cvs version.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 4

15 years ago
It's baaack...  This bug has returned for release 1.3.
Who un-fixed it?

It seems to be a little different now.  In a very long line, on any line but the
first, the left arrow key does exactly nothing at all now.  The right arrow
key's behavior seems to be completely regressed (i.e. jumps to the beginning of
the next display line).  As before, the up and down arrows work properly.

For the record, we're now using GCC 3.2.1 and libc 2.3.1 here.

(For verifying on the Additional Comments field, please keep in mind that the
line must wrap over onto at least the next line; it's somewhat more obvious as
more lines are added [without hitting return :) ].)
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
(Reporter)

Comment 5

15 years ago
It's still present in 1.4 (and makes writing e-mail without using the mouse much
more difficult as well).  And, playing with the Additional Comments field, it
seems to be much more complicated than I had thought.

If the text is typed in at the keyboard, the failure always happens (after the
first visual line of text).

If the text is pasted in from the clipboard (in my case, under X in Linux)
without newlines, this failure always happens.

If I copy the first description paragraph from the bug and paste it in (which
contains newlines) and then remove the newlines...  it doesn't fail in quite the
same way.  If I place the cursor at the end of the line (with the mouse) and
hold down the left arrow key, it stops responding when the cursor moves to the
previous line and a space is hidden to the right of the line... but clicking at
the point it stopped at or pressing up and then down seems to "fix" it in this
case (though this is no help with the previous two cases).  The right arrow key
seems to have no problems in this case.

Comment 6

15 years ago
I can confirm that I see this bug consistently using...
    "Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701" 

But I do not see it when using...
    "Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20021212"

...as mentioned, the problem seems to be largely related to text that is very
long (without line breaks) which is pasted inot a textarea box that wraps. 
However, when typing a lot of text into a text area box, and interspersing that
typed text with some occasional short sections of pasted text, the problem also
occurs -- allthough much less predictably.

Comment 7

15 years ago
I just double checked, and I can *NOT* reproduce this using my Linux 1.3 box...

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030318 Debian/1.3-1.01

(Reporter)

Comment 8

15 years ago
Interesting.  Mozilla is using GTK here -- gtk-1.2.so.0.9.1 -- on a Linux kernel
2.4.22 system.
I see there's a new version of GTK now, so I'll download and install it, and
then test this again.
(Reporter)

Comment 9

15 years ago
... And, as it turns out, GTK 1.2.10 _is_ gtk-1.2.so.0.9.1 , so I'm up-to-date
after all...!
(Reporter)

Comment 10

15 years ago
It's still in 1.6.  Is there anything I could/should do to help this get
confirmed (and eventually fixed)?

Comment 11

14 years ago
I've seen this bug in Mozilla versions 1.4 and 1.6 under Solaris.  It's very
reproducable.  Worse, it seems to have migrated to Thunderbird in 0.5 (it wasn't
in 0.2).  I've not seen this bug, however, under any version under Linux
(doesn't mean it's not there, I've just not seen it).  Interestingly, ctrl+left
and ctrl+right always work as expected (back and forward by word).  This isn't a
big deal, but it can be rather annoying.

Comment 12

14 years ago
>>> This isn't a big deal, but it can be rather annoying.

I disagree, this bug makes using mozilla for anything more then point and click
nearly impossible.  It is the sole reason I still use 1.2.1 on my office Sparc.

Comment 13

14 years ago
This bug appears to be gone from Thunderbird 0.6 on Solaris.  I'm very happy to
again be able to use my arrow keys without wondering what will happen :) 
Hopefully this means that 1.7 will be fixed as well.

Thanks to the devs (or happy coincidence) that made this happen!
(Reporter)

Comment 14

14 years ago
It appears that this bug has vanished again in Mozilla 1.7... or, at least, it's
no longer a problem, now that I've upgraded.  I hope it never returns...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED

Comment 15

14 years ago
No fix specified.

->WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---

Updated

14 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.