[Webkit-unassigned] [Bug 33435] selection.modify("move", "left", "lineboundary") in RTL text moves to the right lineboundary

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Xiaomei Ji <xji at chromium.org>  2010-12-09 10:37:09 PST ---
(From update of attachment 75845)
View in context: https://bugs.webkit.org/attachment.cgi?id=75845&action=review

>>> WebCore/editing/SelectionController.cpp:432
>>> +        break;
>> 
>> We should just do:
>> if (directionOfEnclosingBlock() == LTR)
>>     return visualEndOfLine(startForPlatform());
>> return visualStartOfLine(startForPlatform());
>> 
>> and modify
>> pos = modifyMovingForward(granularity);
>> to
>> return modifyMovingForward(granularity);
>> 
>> I don't know why we have a VisiblePosition local variable in the first place.
> 
> I'm confused about this change now.  Why are we calling different visual* functions depending on the directionality of text block?  Shouldn't visualStartOfLine always return the visually left-most offset?  When we say the start of line in RTL text, is it the right edge of the text?  Because your change seems to indicate that.

The "pos = ..." style is in all modifyMoving.... and modifyExtending.... functions. I feel it is more easier to read and to debug. But I do not have strong opinions on it.

I agree the visualStart/EndOfLine names are confusing. In the current patch,  visual start of line in RTL text is the right edge of text. I think using left/right will be unambiguous, and I will change to that.

>> WebCore/editing/visible_units.cpp:1247
>> +}
> 
> Does this mean that logical/visual behaviors are the same, and we're not changing the behavior at all this in patch?

I am not sure what should be the correct behavior of logical start/end of line.

I just read the draft specs for bidi editing by Matitiahu Allouche of IBM, the chairman of the Standards Institute of Israel's committee on IT aspects of Hebrew.
On "HOME/END" issue it says:
"Home and End keys are logical functions which move the current logical position before the first logical character (whatever its Bidi level) and after the last logical character (of the line, sentence, paragraph etc... according to whatever unit of text the non-bidi Home and End functions relate to).
The caret will be displayed on the leftmost visual position for Home in LTR paragraphs and End in RTL paragraphs, on the rightmost visual position for End in LTR paragraphs and Home in RTL paragraphs. Beside moving the caret position, Home and End must set the caret direction in accordance with the base direction of the the paragraph."

Which matches our current implementation.

In the current patch, MovingLeft/Right on line boundary always moves caret to the left/right edge of the line regardless of containing block's directionality. MovingForward on line boundary moves caret to the right edge of line if the containing block is LTR, and it moves caret to the left edge of the line if the containing block is RTL.

I prefer not changing the logical behavior in the same patch. There is a bug filed against HOME/END issue: https://bugs.webkit.org/show_bug.cgi?id=49107.
If we are going to change that, I'd prefer in a different patch.

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