[Webkit-unassigned] [Bug 85017] enable ctrl-arrow move by word visually in other platforms (besides Windows)

[bugzilla-daemon at webkit.org]

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





--- Comment #12 from Xiaomei Ji <xji at chromium.org>  2012-04-30 17:24:44 PST ---
(From update of attachment 139541)
View in context: https://bugs.webkit.org/attachment.cgi?id=139541&action=review

>> Source/WebCore/editing/EditingBehavior.h:77
>> +    bool shouldSkipSpaceBeforeWord() const { return m_type == EditingWindowsBehavior; }
> 
> I'm sorry but I get more confused by the comment. I would just do:
> // "abc |def |hij |opq" on Windows and "abc| def| hij| opq|" on Mac and Linux when moving forward between word boundaries.
> shouldSkipSpaceAfterWordOnForwardWordBoundaryMovement()
> if I were you (note more verbose function name).

Forward/Backward implies logical. Maybe "shouldSkipSpaceWhenMovingRight"?

>> LayoutTests/editing/selection/move-by-word-visually-mac-expected.txt:90
>> +" abc def AAA AAA hij AAA AAA uvw xyz "[1, 5, 8, 12, 16, 20, 24, 28, 32, 36], <DIV>[0], "AAA kj AAA mn opq AAA AAA"[3, 6, 10, 13, 17, 21, 25]    FAIL expected: [" abc def AAA AAA hij AAA AAA uvw xyz "[ 1,  5,  8,  12,  16,  20,  24,  28,  32,  36, ]"AAA kj AAA mn opq AAA AAA"[ 3,  6,  10,  13,  17,  21,  25]
> 
> Why is this case failing? Offsets do match here.

when moving left, it stops at the first empty line (<div><br><div>) whose position is <div>[0].

>> LayoutTests/editing/selection/move-by-word-visually-mac-expected.txt:103
>> +"    abc    def    hij    opq    "[28, 22, 15, 8, 4]
> 
> Why is the second position 22? Shouldn't it be 25? And then 18, 11, then 4?
> It seems odd to use a position between whitespaces like this.

that is what returned in VisiblePosition. (22) and (25) should be equivalent. But I am not sure how our space collapse works.

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