|Summary:||RTL Regression: Caret position is wrong when typing RTL text in a LTR text box or type LTR text in a RTL text box|
|Product:||WebKit||Reporter:||Xiaomei Ji <xji>|
|Severity:||Minor||CC:||aharon, jturcotte, mitz, playmobil, progame+wk, rniwa, xji|
|Version:||525.x (Safari 3.2)|
Description Xiaomei Ji 2009-03-01 15:12:37 PST
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.
Comment 2 Xiaomei Ji 2009-03-01 15:15:22 PST
also in Chrome: http://code.google.com/p/chromium/issues/detail?id=8172
Comment 3 email@example.com 2009-03-01 15:36:23 PST
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.
Comment 4 Xiaomei Ji 2009-03-01 16:22:30 PST
*** Bug 24279 has been marked as a duplicate of this bug. ***
Comment 5 Xiaomei Ji 2009-03-01 16:24:45 PST
(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.
Comment 6 Yair Yogev 2009-03-01 22:05:22 PST
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)
Comment 7 firstname.lastname@example.org 2009-03-01 22:10:49 PST
(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) >
Comment 8 Yair Yogev 2009-03-01 22:14:02 PST
thanks, i guess IE and FF identify it wrong
Comment 9 Xiaomei Ji 2009-06-04 15:14:56 PDT
(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.
Comment 10 email@example.com 2009-06-04 16:03:43 PDT
(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
Comment 11 Jocelyn Turcotte 2010-03-17 11:11:50 PDT
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.
Comment 12 Yair Yogev 2010-03-17 11:46:53 PDT
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.
Comment 14 Ryosuke Niwa 2011-03-30 02:50:20 PDT
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.