[Webkit-unassigned] [Bug 53696] Caret is rendered at an incorrect position at the boundary of Arabic number in a LTR context

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=53696





--- Comment #25 from Ryosuke Niwa <rniwa at webkit.org>  2011-02-27 22:05:41 PST ---
(In reply to comment #24)
> (In reply to comment #23)
> > In particular, how do I know which offset corresponds to which insertion point location?
> 
> I usually just press Return to insert a newline to see where I was :)

Using this method, I found that the caret is at offset 2 if the text direction is explicitly set to RTL but it's at offset 0 if the text direction is explicitly set to LTR.

Now, if I set the text direction to LTR, and put the caret on the rightmost boundary by clicking on the far right of the text, then the split caret shows up on the upper rightmost corner and the lower leftmost corner.  If I then press left key (assuming selection is on default mode), then the lower caret moves to the boundary between arabic letters and numerals.  And pressing enter here results in inserting \n at offset 2 as well.  And this lower caret is what I was trying to implement.

Now, TextEdit seems to have various insertion point bugs with this particular input.  In particular, putting the insertion point between alphabet and numeral, and then moving to the left results in infinite loop on the single letter ‎ر.  Given that I'm not even sure if we should try to mimic TextEdit or NSTextView.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.