Open Bug 462452 Opened 16 years ago Updated 3 years ago

Selection expands in wrong direction when contenteditable, RTL element contains LTR characters

Categories

(Core :: DOM: Editor, defect, P5)

x86
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: zwol, Unassigned)

Details

Attachments

(1 file)

Attached file test case
If you have a contenteditable element that has been explicitly labeled as RTL (with HTML attributes or CSS properties) but bidi-override is not in effect, and the content of that element is LTR characters, then Shift+arrow keys expand or shrink the selection in the opposite direction from what is appropriate.

In the attached test case, both the area with Latin letters and the area with Hebrew letters are contenteditable.  In both areas, when there is no selection, the left and right arrow keys move the caret left and right, respectively.  In the area with Hebrew letters, Shift+left moves one edge of the selection left, and Shift+right moves one edge of the selection right.  But in the area with Latin letters, Shift+left moves an edge of the selection right, and Shift+right moves an edge of the selection left.

This may be related to bug 456622 but is probably not exactly the same.
Further: caret movement in the editable Latin region is only "backwards" when bidi.edit.caret_movement_style is 0 or 2.  However, in all three modes it is *not* "backwards" in the editable Hebrew region.  (I would have expected it to go "backwards" in Hebrew when that pref was zero, but it doesn't!)

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: