Bug 64392

Summary:

Caret should move immediately before a word when modifying selection by word granularity on Windows

Product:

WebKit

Reporter:

David Tseng <dtseng>

Component:

HTML Editing

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

aroben, darin, enrica, justin.garcia, mitz, mrobinson, rniwa, xji

Priority:

Version:

528+ (Nightly build)

Hardware:

OS:

Windows 7

Attachments:

Description	Flags
Proposed patch.	rniwa: review-

David Tseng

Reported 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.

Attachments
Proposed patch. (1.52 KB, patch) 2011-07-19 14:57 PDT, David Tseng	rniwa: review-	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Ryosuke Niwa

Comment 1 2011-07-12 14:39:33 PDT

http://crbug.com/88711

David Tseng

Comment 2 2011-07-19 14:57:20 PDT

Created attachment 101393 [details] Proposed patch.

Ryosuke Niwa

Comment 3 2011-07-19 15:08:30 PDT

Comment on attachment 101393 [details] Proposed patch. We definitely need a test for this.

Ryosuke Niwa

Comment 4 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?

Darin Adler

Comment 5 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.

Ryosuke Niwa

Comment 6 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.

Ryosuke Niwa

Comment 7 2011-08-08 12:39:37 PDT

Comment on attachment 101393 [details] Proposed patch. Clearing cq? since this patch has been r-ed.

Ryosuke Niwa

Comment 8 2012-05-01 23:39:45 PDT

Xiaomei, is this bug fixed per your visual word movement patch?

Xiaomei Ji

Comment 9 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.

Note You need to log in before you can comment on or make changes to this bug.