Closed Bug 320957 Opened 14 years ago Closed 14 years ago
Right-arrow misbehaves after deleting a single RTL character following LTR text at end of line in RTL textarea
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.
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.
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").
Depends on: 303884
Fixed by the patch for bug 303884.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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.