BiDi: In an LTR textarea, when a line ends with one or more RTL words, ctrl+right-arrow never moves the caret to the next line

RESOLVED FIXED in mozilla1.9alpha1



Layout: Text
13 years ago
9 years ago


(Reporter: Prognathous, Assigned: Uri Bernstein (Google))



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: See comment #2 for testcase instructions)


(1 attachment)



13 years ago
To reproduce:

1. Open
2. Put the caret in the begining of the second textarea (LTR textarea, first
line, left corner)
3. Press the Ctrl+RightArrow 3 times (or more)

Result: The caret moves to the left of the letter Alef, but then remains stuck
in this position regardless of additional key-presses.

The same problem happens in the RTL textarea when pressing Ctrl+LeftArrow, but
in this case, it also happens with just LeftArrow (see Bug 299239 for more
details). I'm reporting this one as a seperate bug as per Bug 299239, comment #2.

Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050702 Firefox/1.0+


Comment 1

12 years ago
The problem with the RTL textarea (which was, BTW, a problem with a single LTR
word, not just a single LTR character), was fixed by Eyal's patch for bug 299239
(unlike my previously proposed patch which only took care of the "regular"
left-arrow case).

The problem in the LTR textarea is actually a bit different than what's
described in comment #0. Specifically: it only occurs at end of lines; it occurs
with a single RTL word (not necessarily single character); and it also occurs
(in a slightly different form) with multiple RTL words.

The current testcase is also affected by bug 303399. I'll attach a new testcase
with detailed instructions soon.
Summary: BiDi: Caret is stuck when reaching a single character in opposite direction using Ctrl+Arrow (effects both RTL and LTR textares) → BiDi: In an LTR textarea, when a line ends with one or more RTL words, ctrl+right-arrow never moves the caret to the next line

Comment 2

12 years ago
Created attachment 192967 [details]

The problem is only in the second (LTR) text area, in the first three lines.

In the first line, place the caret anywhere on the line and press ctrl+right
arrow repeatedly. The caret reaches the extreme right of the line and remains
In the second line, do the same. The caret cycles between the right edges of
the two RTL words (but never moves on to the next line).
The third line is similar - the caret cycles between the three RTL words.

Lines 3-6 demonstrate that this does not happen when the RTL words are not at
the end of the line. (These lines do exhibit bug 304891, which is not


12 years ago
Whiteboard: See comment #2 for testcase instructions

Comment 3

12 years ago
Following the fix to bug 304891 (I think), back in September 2005, this bug only happens when layout.word_select.eat_space_to_next_word=flase, that is, by default it only affects Mac and Linux, but not Windows.

Note that the testcases on this bug still suffer from bug 299535, on all platforms.

Comment 4

12 years ago
The patch I have for bug 299240 (which depends on bug 331444 being fixed first) also fixes this bug.
Depends on: 299240

Comment 5

12 years ago
Fixed by the fix for bug 299240.
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha

Comment 6

10 years ago
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl


9 years ago
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.