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.
Created attachment 28154 [details] test case
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.
*** Bug 24279 has been marked as a duplicate of this bug. ***
(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.
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) >
thanks, i guess IE and FF identify it wrong
(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
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.
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.
a fix here will affect Bug 33503 btw
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.