Bug 152635 – Caret displays in the wrong place in an RTL text field

• Component: Forms
• Status: NEW

[Simon Fraser (smfr)]

Created attachment 268067 [details]
Testcase; type in the second field

When typing in an RTL text input, the caret shows on the left side, even though characters are being inserted on the right side.

This seems to be behaving correctly, and in agreement with Cocoa text fields (when not using a split caret): roughly speaking, in a right-to-left paragraph, the caret position indicates where the next right-to-left character would appear.

[Simon Fraser (smfr)]

But it doesn't agree with Firefox, and seems confusing; the characters don't appear where the caret is, when it's at the start or end of the field.

In addition, shift-right-arrow expands the selection to the left.

[Simon Fraser (smfr)]

Cocoa shows a split caret in the instances where we get it wrong (at the ends).

(In reply to comment #2)
> But it doesn't agree with Firefox, and seems confusing; the characters don't
> appear where the caret is, when it's at the start or end of the field.

You are talking about the exceptional case of typing a character whose directionality is opposite the text field’s directionality, right?

> In addition, shift-right-arrow expands the selection to the left.

This is a separate issue. Some bugs in arrow key behavior have been fixed, and addressing some bugs involving arrow-selection requires supporting multiple-range selections first.

(In reply to comment #3)
> Cocoa shows a split caret in the instances where we get it wrong (at the
> ends).

WebKit doesn’t support a split caret yet (see bug 3710). WebKit’s caret positioning in OS X matches that of Cocoa when the optional split caret feature is turned off.

(In reply to comment #4)
> WebKit’s caret positioning in OS X matches that of Cocoa when the optional split
> caret feature is turned off.

(Meaning WebKit draws only the primary caret).