[Webkit-unassigned] [Bug 25298] Ctrl + Right/Left arrow move forward/backward through document instead of right/left in RTL text

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu May 27 17:00:21 PDT 2010


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





--- Comment #9 from Xiaomei Ji <xji at chromium.org>  2010-05-27 17:00:20 PST ---
Created an attachment (id=57283)
 --> (https://bugs.webkit.org/attachment.cgi?id=57283)
unfinished patch

Hi Mitz,

I am trying to fix the issue by creating the string in visual order sequence, then finding the word boundary within the string, and convert the boundary offset within the string into DOM position finally.

I only changed the ctrl-left-arrow part.
It works correctly for bidi text in RTL div, LTR div, RTL div with span, and LTR div with span.

But it does not work correctly for bidi text in RTL div with LTR span or LTR div with RTL span.

Given the following example:
<div contenteditable dir=rtl>abc ששש def <span dir=ltr>שנב  abc סטז</span>  uvw זזז xyz</div> 

ctrl-left-arrow does not work correctly when caret is around the Hebrew characters inside the <span>.

The position information in some of the positions inside <span> looks like a bug to me, which caused the ctrl-left-arrow does not move correctly.

Below, I am using "(node, offset)a" to represent the node and offset information of position when caret is before character "a". 

Assume "שנב abc  סטז" is node A and "abc ששש def " is node B.

(A, 3)ב(A, 2)נ(A, 1)ש(B, 0xc) (A, 4)a(A, 6)b(A, 7)c(A, 8) (A, 0xc)ז(A, 0xB)ט(A, 0xa)ס(A, 9).

The position information (B, 0xc) looks like a bug. position (A, 4) or (A, 6) looks like a bug too (why (A, 5) is missing?).

The above node has 4 runs, their (start, length) are (0, 3), (3, 1), (5, 4), and (9, 3).
The information (5, 4) looks like a bug. Why it starts at 5, which is not continuous with previous run?

Based on the above information, when caret is after the rightmost Hebrew character 'ס', leftWordPosition() will find the word break is at string offset 4 when the string is "abc סטז", then it adds offset 4 to the 3rd run's start offset 5 to get the offset within node A, which is 9. And the position (A, 9) is where the caret is at originally.


Given an example of LTR div with RTL span, such as 
<div contenteditable>abc ששש def <span dir=rtl>שנב  abc סטז</span>  uvw ששש xyz</div>

I am not able to mouse click to put the caret before 'a' inside the <span>. left-arrow and right-arrow do not work correctly inside <span> either, and it is not able to place caret before 'a' using arrow key.
Maybe related to position information too.


I feel the position computation is wrong given the above example, it might be computed wrongly in bidi resolver or somewhere else.
Or I am in the wrong direction of fixing the issue.

Would like to get your opinion.

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


More information about the webkit-unassigned mailing list