Bug 64392 - Caret should move immediately before a word when modifying selection by word granularity on Windows
Summary: Caret should move immediately before a word when modifying selection by word ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-12 14:30 PDT by David Tseng
Modified: 2012-05-02 11:15 PDT (History)
8 users (show)

See Also:


Attachments
Proposed patch. (1.52 KB, patch)
2011-07-19 14:57 PDT, David Tseng
rniwa: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Tseng 2011-07-12 14:30:30 PDT
1.  place focus on a textfield or textarea (i.e. google.com, search field).
2.  type a sentence (i.e. "this is a test").
3.  press ctrl-right several times and then ctrl-left several times.

What is the expected result?
each press of ctrl-right places cursor before next word.  Example:
this |is a test.
this is |a test.
this is a |test.

Currently, webkit places the cursor *after* the current word.
this| is a test.
this is| a test.
this is a| test.

This though consistent with Mac cursor movement, isn't in Windows.
Comment 1 Ryosuke Niwa 2011-07-12 14:39:33 PDT
http://crbug.com/88711
Comment 2 David Tseng 2011-07-19 14:57:20 PDT
Created attachment 101393 [details]
Proposed patch.
Comment 3 Ryosuke Niwa 2011-07-19 15:08:30 PDT
Comment on attachment 101393 [details]
Proposed patch.

We definitely need a test for this.
Comment 4 Ryosuke Niwa 2011-07-19 15:16:17 PDT
Comment on attachment 101393 [details]
Proposed patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=101393&action=review

> Source/WebCore/platform/text/TextBoundaries.cpp:74
> -            if (position < len && isAlphanumeric(chars[position - 1]))
> +            if (position < len && isAlphanumeric(chars[position]))

This code seems to be used by GTK as well.  Are we sure we want this behavior on GTK?
Comment 5 Darin Adler 2011-07-19 15:18:55 PDT
Comment on attachment 101393 [details]
Proposed patch.

I don’t think this is the right level to make this policy change.

Further, this should probably be a behavior change that is conditional based on text editing behavior. It’s a coincidence right now that this code isn’t used on Mac, for example.
Comment 6 Ryosuke Niwa 2011-07-19 15:26:35 PDT
(In reply to comment #5)
> (From update of attachment 101393 [details])
> I don’t think this is the right level to make this policy change.
> 
> Further, this should probably be a behavior change that is conditional based on text editing behavior. It’s a coincidence right now that this code isn’t used on Mac, for example.

I agree. Changing behavior based on EditingBehavior is much cleaner.
Comment 7 Ryosuke Niwa 2011-08-08 12:39:37 PDT
Comment on attachment 101393 [details]
Proposed patch.

Clearing cq? since this patch has been r-ed.
Comment 8 Ryosuke Niwa 2012-05-01 23:39:45 PDT
Xiaomei, is this bug fixed per your visual word movement patch?
Comment 9 Xiaomei Ji 2012-05-02 11:15:50 PDT
(In reply to comment #8)
> Xiaomei, is this bug fixed per your visual word movement patch?

Yes. and I am closing it.