24278 2009-03-01 15:12:37 -0800 RTL Regression: Caret position is wrong when typing RTL text in a LTR text box or type LTR text in a RTL text box 2011-03-30 02:50:20 -0700 1 1 1 Unclassified WebKit Forms 525.x (Safari 3.2) PC Windows XP NEW PlatformOnly P2 Minor --- 1 xji webkit-unassigned aharon jturcotte mitz playmobil progame+wk rniwa xji oldest_to_newest 111750 0 xji 2009-03-01 15:12:37 -0800 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. 111751 1 28154 xji 2009-03-01 15:13:58 -0800 Created attachment 28154 test case 111752 2 xji 2009-03-01 15:15:22 -0800 also in Chrome: http://code.google.com/p/chromium/issues/detail?id=8172 111757 3 mitz 2009-03-01 15:36:23 -0800 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. 111762 4 xji 2009-03-01 16:22:30 -0800 *** Bug 24279 has been marked as a duplicate of this bug. *** 111763 5 xji 2009-03-01 16:24:45 -0800 (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. 111780 6 progame+wk 2009-03-01 22:05:22 -0800 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) 111781 7 mitz 2009-03-01 22:10:49 -0800 (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) > 111782 8 progame+wk 2009-03-01 22:14:02 -0800 thanks, i guess IE and FF identify it wrong 124386 9 xji 2009-06-04 15:14:56 -0700 (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. 124397 10 mitz 2009-06-04 16:03:43 -0700 (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 200870 11 jturcotte 2010-03-17 11:11:50 -0700 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. 200889 12 50929 progame+wk 2010-03-17 11:46:53 -0700 Created attachment 50929 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. 213431 13 progame+wk 2010-04-16 14:32:17 -0700 a fix here will affect Bug 33503 btw 376154 14 rniwa 2011-03-30 02:50:20 -0700 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. 28154 2009-03-01 15:13:58 -0800 2009-03-01 15:13:58 -0800 test case 8172.html text/html 59 xji PGh0bWw+DQo8dGV4dGFyZWEgcm93cz0iMiIgY29scz0iMjAiPg0KPC90ZXh0YXJlYT4NCjwvaHRt bD4= 50929 2010-03-17 11:46:53 -0700 2010-03-17 11:46:53 -0700 new test case testcase24278.htm text/html 543 progame+wk PEhUTUw+PEhFQUQ+PE1FVEEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKPFNUWUxFPgoKPC9TVFlMRT4KPC9IRUFEPjxCT0RZPgp3 cml0ZSBzb21lIExUUiB0ZXh0IGhlcmUgKEVuZ2xpc2ggd291bGQgYmUgZmluZS4uLik8YnI+CjxU RVhUQVJFQSBkaXI9InJ0bCI+CjwvVEVYVEFSRUE+PHA+CmFuZCBoZXJlOjxicj4KICA8aW5wdXQg ZGlyPSJydGwiPjxicj4KKG5vdGUgaG93IHlvdSBjYW4ndCBzZWUgd2hhdCB5b3UgdHlwZSBpbiB0 aGUgc2Vjb25kIGJveCBhZnRlciBmaWxsaW5nIHRoZSB2aXNpYmxlIHNwYWNlKQo8cD4Kd3JpdGUg c29tZSBSVEwgdGV4dCBoZXJlOiAoSGVicmV3XEFyYWJpYy4uLik8YnI+CjxURVhUQVJFQT4KPC9U RVhUQVJFQT48cD4KYW5kIGhlcmU6PGJyPgo8aW5wdXQ+PGJyPgoobm90ZSBob3cgeW91IGNhbid0 IHNlZSB3aGF0IHlvdSB0eXBlIGluIHRoZSBzZWNvbmQgYm94IGFmdGVyIGZpbGxpbmcgdGhlIHZp c2libGUgc3BhY2UpCgoKIDwvQk9EWT48L0hUTUw+