[Webkit-unassigned] [Bug 24303] Using keyboard select RTL text, Highlight goes to opposite direction from FF&IE

[bugzilla-daemon at webkit.org]

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





------- Comment #5 from mitz at webkit.org  2009-03-04 23:07 PDT -------
(In reply to comment #4)
> If this is a bug in WebKit,
> can we change SelectionController::modifyExtendingRightForward(),
> in the cases of CharacterGranularity and WordGranularity, check whether
> "pos.deepEquivalent().node()->renderer()->style()->direction() ==
> WebCore::RTL",
> extend selection to leftBackward if it is RTL, and extend selection to
> rightForward if it is LTR?
> 
> Or maybe introduce a new method to handle the forward/backward based on element
> style as above.
> 
> Same applies to SelectionController::modifyExtendingLeftBackward().

I think the methods should be split into modifyExtendingForward(),
modifyExtendingBackward(), which should retain the existing behavior, and
modifyExtendingRight() and modifiyExtendingLeft(), which should behave
"visually", essentially mimicking what was done for modifyMoving* in
<http://trac.webkit.org/changeset/32605>.

I do not think that examining the direction property of the renderer would lead
to the best results. I am unfamiliar with the Windows and Firefox behavior, but
in the Cocoa text system on Mac OS X, the actual direction of the text runs
(i.e. the resolved bidi level) is ultimately used to determine the position to
move the selection's extent to; this is very similar to how moving the
selection works in WebKit following r32605. So I think a better approximation
of the desired behavior would be to use VisualPosition::right() and
VisualPosition::left() to determine where to move the extent to, and refine as
necessary and as possible when the extent is at a boundary between levels,
although as long as Selection is limited to a single range, there is only so
much that can be done to maintain the "visual" behavior in the bidirectional
cases.


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