[Webkit-unassigned] [Bug 59652] turn on move caret by word visually for windows platform.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 28 22:16:39 PDT 2011


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





--- Comment #10 from Xiaomei Ji <xji at chromium.org>  2011-04-28 22:16:39 PST ---
(In reply to comment #9)
> (From update of attachment 91604 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=91604&action=review
> 
> > Source/WebCore/ChangeLog:10
> > +        Tests: editing/selection/move-left-right-by-word.html
> > +               platform/win/editing/selection/move-left-right-by-word.html
> 
> The tests shouldn't be in platform directories now. All platforms should test both behaviors.


The test only tests sel.modify("move", "left"/"right", "word").

We could have only one test file but with different expectations in different platforms.
The reason why we have 2 test files is because I put test expectations inside the test file itself.

Ryosuke suggested to put test expectation inside test file so that if anyone breaks the test, the test reports "FAILED....." to avoid being blindly rebased.
I think it is a good idea, and I am also using the expectation to test word break stops at correct place on every visible position when the caret movement is following visual order.

When you look at the 2 test files, one is passing "visual" to runTest(), and the other is passing "logical" to runTest(). Seems that they are testing different behaviors.
But underlying, they both just test sel.modify("move", "left"/"right", "word").

The "visual" vs. "logical" parameter is just used to guide the direction of the modify as explained below.
Inside the test, on each line of text, I first set the initial selection postion to 0, then move the caret by word in one direction till reach the end, then move it to the opposite direction till end.

If the implementation of sel.modify() is moving caret by word in visual order, 
when initial position is 0, if the text is in LTR context, it needs to move "right" till end, then move "left" till end. If the text is in RTL context, it needs to move "left" till end, then move "right" till end.

If the implementation of sel.modify() is moving caret by word in logical order,
when initial position is 0, we always move "right" (which is equivalent to move "forward') till end, then move "left" (which is equivalent to move "backward") till end.

That is when "visual" vs. "logical" is used (to indicate whether we should move "left" or "right" first, then, move to the other direction).


> 
> > LayoutTests/platform/win/editing/selection/move-left-right-by-word.html:22
> > +<script src="../../../../editing/selection/resources/move-left-right-by-word.js"></script>
> 
> Please don't split tests into html and js parts. I can see how this can be helpful when there are separate htmls in platform directories, but this can be one file that tests both behaviors.

You are right. The js is extracted to be shared.

I realized that I should skip editing/selection/move-left-right-by-word.html in win/ and chromium-win/. Or else, I probably need to put this test under all other platforms.

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



More information about the webkit-unassigned mailing list