2011-03-30 Xiaomei Ji <xji@chromium.org>
authorxji@chromium.org <xji@chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 31 Mar 2011 16:17:25 +0000 (16:17 +0000)
committerxji@chromium.org <xji@chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 31 Mar 2011 16:17:25 +0000 (16:17 +0000)
commitacc4ac847aa17628b3a4cc3494df723c6430047e
tree3d15f8b9de49d0c79b711571e762d80ea33e590a
parent54c64a10b365e911a710d7da5c1cec8f95177e7a
2011-03-30  Xiaomei Ji  <xji@chromium.org>

        Reviewed by Ryosuke Niwa.

        Experiment with moving caret by word in visual order.
        https://bugs.webkit.org/show_bug.cgi?id=57336

        * editing/selection/move-by-word-visually-expected.txt: Added.
        * editing/selection/move-by-word-visually.html: Added.
2011-03-30  Xiaomei Ji  <xji@chromium.org>

        Reviewed by Ryosuke Niwa.

        Experiment with moving caret by word in visual order.
        https://bugs.webkit.org/show_bug.cgi?id=57336

        Follow Firefox's convention in Windows,
        In LTR block, word break visually moves cursor to the left boundary of words,
        In RTL block, word break visually moves cursor to the right boundary of words.

        This is the 1st version of implementing "move caret by word in visual order".
        It only works in the following situation:
        1. For a LTR box in a LTR block or a RTL box in RTL block,
        when caret is at the left boundary of the box and we are looking for
        the word boundary in right.
        2. For a LTR or RTL box in a LTR block, when caret is at the left boundary
        of the box and we are looking for the word boundary in left and
        previous box is a LTR box.
        3. For a LTR or RTL box in a RTL block, when the caret is at the right
        boundary of the box and we are looking for the word boundary in right and next box is RTL box.

        An experimental granularity is introduced, as a side effect, functions having switch statements
        to handle those granularities have to add more one case to handle this new granularity.
        The experimental granularity is exposed though JS by '-webkit-visual-word".

        The overall algorithm is looping through inline boxes visually and looking
        for the visually nearest word break position.

        Test: editing/selection/move-by-word-visually.html

        * editing/SelectionController.cpp:
        (WebCore::SelectionController::modifyExtendingRight):
        (WebCore::SelectionController::modifyExtendingForward):
        (WebCore::SelectionController::modifyMovingRight):
        (WebCore::SelectionController::modifyMovingForward):
        (WebCore::SelectionController::modifyExtendingLeft):
        (WebCore::SelectionController::modifyExtendingBackward):
        (WebCore::SelectionController::modifyMovingLeft):
        (WebCore::SelectionController::modifyMovingBackward):
        * editing/TextGranularity.h:
        * editing/VisibleSelection.cpp:
        (WebCore::VisibleSelection::setStartAndEndFromBaseAndExtentRespectingGranularity):
        * editing/visible_units.cpp:
        (WebCore::previousWordBreakInBoxInsideBlockWithSameDirectionality):
        (WebCore::wordBoundaryInBox):
        (WebCore::wordBoundaryInAdjacentBoxes):
        (WebCore::leftWordBoundary):
        (WebCore::rightWordBoundary):
        (WebCore::leftWordPosition):
        (WebCore::rightWordPosition):
        * editing/visible_units.h:
        * page/DOMSelection.cpp:
        (WebCore::DOMSelection::modify):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@82588 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/editing/selection/move-by-word-visually-expected.txt [new file with mode: 0644]
LayoutTests/editing/selection/move-by-word-visually.html [new file with mode: 0644]
Source/WebCore/ChangeLog
Source/WebCore/editing/SelectionController.cpp
Source/WebCore/editing/TextGranularity.h
Source/WebCore/editing/VisibleSelection.cpp
Source/WebCore/editing/visible_units.cpp
Source/WebCore/editing/visible_units.h
Source/WebCore/page/DOMSelection.cpp