Bug 24278 – RTL Regression: Caret position is wrong when typing RTL text in a LTR text box or type LTR text in a RTL text box

• Status: NEW
• Component: Forms

[Xiaomei Ji]

This is a regression.
It works correctly in Sarafi 3.2, but not in nightly r41128.

Test case is attached.

Type a Hebrew (for example) word in the text box at the buttom of the test
page. 

The caret should stay left, as that's where the last typed letter is.
(FF and IE behaves like this).

In Safari, the caret moves to the right part of the word.

[Xiaomei Ji]

Created attachment 28154 [details]
test case

[Xiaomei Ji]

also in Chrome:
http://code.google.com/p/chromium/issues/detail?id=8172

The behavior is correct for Mac OS X. Note that in Firefox, the position (and shape, see bug 22386) of the insertion point changes depending on the active keyboard layout, so that in the attached test case, if one types RTL characters using the Hebrew keyboard layout and then changes the keyboard layout to U.S., the insertion point moves to the right. In Mac OS X, the position to the right may be indicated by a split caret (see bug 3710), but that does not depend on the active keyboard layout.

[Xiaomei Ji]

*** Bug 24279 has been marked as a duplicate of this bug. ***

[Xiaomei Ji]

(merged from bug 24279).

Also, Caret position is wrong when typing LTR text in a RTL text box.

Type a English word in a RTL text box. 

The caret should move to right, as that's where the last typed letter is.
(FF and IE behaves like this).

In Safari, the caret always stays at the very left.

[Yair Yogev]

there is also this specific website:
http://guide.maccabi4u.co.il/SearchChapter.aspx?ChapterId=1
where when writing a Hebrew word in this RTL text box:
http://img24.imageshack.us/img24/8255/chromecaret2.jpg

the caret doesn't move to the left, although the word and the textbox is RTL

this is also a regression, older builds works fine with it
(it is only applicable to the text box shot in the screenshot)

(In reply to comment #6)
> there is also this specific website:
> http://guide.maccabi4u.co.il/SearchChapter.aspx?ChapterId=1
> where when writing a Hebrew word in this RTL text box:
> http://img24.imageshack.us/img24/8255/chromecaret2.jpg
> 
> the caret doesn't move to the left, although the word and the textbox is RTL

The Web Inspector shows that that input element's 'direction' property's value is 'ltr'. 'text-align' and 'direction' are not the same thing.

> 
> this is also a regression, older builds works fine with it
> (it is only applicable to the text box shot in the screenshot)
> 

[Yair Yogev]

thanks,
i guess IE and FF identify it wrong

[Xiaomei Ji]

(In reply to comment #3)
> The behavior is correct for Mac OS X. 

using TextEditor  in Mac OS X 10.5.6,
when typing Hebrew in left aligned text, the caret stays left.
when typing English character in right aligned text, the caret stays right.

(In reply to comment #9)
> (In reply to comment #3)
> > The behavior is correct for Mac OS X. 
> 
> using TextEditor  in Mac OS X 10.5.6,
> when typing Hebrew in left aligned text, the caret stays left.
> when typing English character in right aligned text, the caret stays right.

TextEdit uses “natural writing direction” by default. If you want to mimic the test case, you should choose Left to Right writing direction from the context menu in TextEdit

[Jocelyn Turcotte]

I can reproduce the "RTL string in LTR text box" case in QtWebKit, Chrome and Safari on Windows.

I can reproduce the "LTR string in RTL text box" only in QtWebKit or in Safari if I explicitely set the text box to RTL in its context menu.
The default direction (for example on google.com.lb) seems to switch the text box to LTR if the string starts with latin characters.

The biggest annoyance is that you don't see what you type when you type text larger than the text box.

[Yair Yogev]

Created attachment 50929 [details]
new test case

This test case allows testing "LTR string in RTL text box" as well as "RTL string in LTR text box".
It also shows how you can't see what you type after filling the visible space because the caret is in the wrong position.

[Yair Yogev]

a fix here will affect Bug 33503 btw

[Ryosuke Niwa]

It seems like this is an inherent problem to the way WebKit maps visual positions to logical positions since we have exactly one visual position for each logical position.  Unless we use Firefox-like hints, we can't resolve this bug without regressions LTR in LTR / RTL in RTL cases.