320957 - Right-arrow misbehaves after deleting a single RTL character following LTR text at end of line in RTL textarea

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Uri Bernstein]

Yet another one.
In an RTL testarea, when a line ends with some LTR text followed by a single RTL character (or a neutral character, resolved to an odd embedding level), deleting that character (e.g. using backspace), and then pressing right-arrow once, moves the caret as if it were at the right edge of the LTR case (instead of the left edge, where it actually is).

The symmetrical case (LTR textarea, RTL text followed by a single LTR character at end of line), used to be similarly broken, but was apparently fixed by the fix to bug 305798.

Testcase will follow soon.

Comment 1

[Uri Bernstein]

Attachment: testcase

In either of the RTL textareas (1st or 3rd):
-Place the caret at the left edge of the first line of text (left of the period)
-Press backspace to delete the period. The caret appears correctly to the left of the "E".
- Press right-arrow.
The caret is incorrectly positioned to the right of space on the right of the "h" (i.e. to the left of the leftmost Hebrew character).
Expected: The caret should be positioned between the "E" and the "n".

The symmetrical problem occures in the LTR textareas in Gecko 1.8, but not in recent trunk builds.

Comment 2

[Uri Bernstein]

This turns out to be similar to bug 303884: the caret ends up in the BRFrame, and the algorithm for determining visual ordering gets confused.
I verified that this would be fixed by the first patch on bug 303884 ("alternative A"). It would also probably be fixed by the second one ("alternative B").

Comment 3

[Uri Bernstein]

Fixed by the patch for bug 303884.

Comment 4

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).