[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]

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





--- Comment #44 from Xiaomei Ji <xji at chromium.org>  2011-03-28 04:47:25 PST ---
Hi Dan,

I talked with Uri about the patch.
Basically, high-level wise, the patch follows what Firefox does as following (extracted from Uri's email).
One of the differences is that Firefox uses space as word breaker while WebKit uses word-breaker which is a logical word breaker.

As to the bidi-level, Uri mentioned that it might be a good start to only consider bidi level  0, 1, and 2. 
I am currently ignoring bidi-level (like assuming bidi level are 0 or 1), which from Uri might be ok as the first step.

Other questions are:
1. The Mac's  native behavior is control-arrow moves caret in logical order (although it is really broken if you try a bidi text that logically begins with English word, then, Hebrew word, then English word. ctrl-right-arrow will be in dead-loop when there are 4 Hebrew words). If you want to keep Mac platform's behavior the same as native's, I can make this patch only work for other platforms.

2. Currently, Firefox in Mac and Windows behaves differently (by default, and is controlled by a config):
In Windows, ctrl-arrow always moves caret to the left boundary of a word in LTR block, and ctrl-arrow always moves caret to the right boundary of a word in RTL block.
In Mac, ctrl-left-arrow moves caret to the left boundary of a word, while  ctrl-right-arrow moves caret to the right boundary of a word.
If we are going to provide a cross-platform behavior as the first step, which behavior we should follow?


FYI: following is the email from Uri about how Firefox implemented it:

"The Mozilla source code for detecting where to stop when handling word-by-word movement is (mostly) at http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#5461.

.....

Background: It's important to understand Mozilla's rendering code's concept of "frame". For our purposes the most important type of frame is TextFrame. The key is that a TextFrame is always unidirectional. So a bidi HTML inline element is broken into multiple frames (non-bidi elements could also span a fe frames - as a frame can never span multiple lines).

The loop you see at lines 5492-5523 loops over frames (as long as there's need to continue), and for each (unidirectional!) frame, calls PeekOffsetWord(), which looks for an appropriate stopping position (roughly, a word boundary) within that frame. The outer loop uses GetFrameFromDirection(), which iterates over frames visually. For each frame encountered, IsMovingInFrameDirection() decides (roughly) weather the curent frame has to be searched forward from its beginning or backwards from its end - based on the direction of movement and the direction (LTR/RTL) of the frame and the containing block element. The output of this is then passed to PeekOffsetWord() which searches the frame accordingly.

The net effect of all of this is that the text is searched, letter-by-letter, in visual order, for an appropriate place to break."

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