Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(88)

Issue 195062: Supports control characters, like what Windows does.... (Closed)

Created:
11 years, 3 months ago by James Su
Modified:
9 years, 7 months ago
CC:
chromium-reviews_googlegroups.com, mikesmith_google.com
Visibility:
Public.

Description

Supports control characters, like what Windows does. This CL fixes issue 21471 by implementing the support of control characters. For the reason of issue 21471, please refer to the code of EditorClientImpl::handleEditingKeyboardEvent() (webkit/glue/editor_client_impl.cc around line 601): ... // Here we need to filter key events. // On Gtk/Linux, it emits key events with ASCII text and ctrl on for ctrl-<x>. // In Webkit, EditorClient::handleKeyboardEvent in // WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp drop such events. // On Mac, it emits key events with ASCII text and meta on for Command-<x>. // These key events should not emit text insert event. // Alt key would be used to insert alternative character, so we should let // through. Also note that Ctrl-Alt combination equals to AltGr key which is // also used to insert alternative character. // http://code.google.com/p/chromium/issues/detail?id=10846 // Windows sets both alt and meta are on when "Alt" key pressed. // http://code.google.com/p/chromium/issues/detail?id=2215 // Also, we should not rely on an assumption that keyboards don't // send ASCII characters when pressing a control key on Windows, // which may be configured to do it so by user. // See also http://en.wikipedia.org/wiki/Keyboard_Layout // TODO(ukai): investigate more detail for various keyboard layout. if (evt->keyEvent()->text().length() == 1) { UChar ch = evt->keyEvent()->text()[0U]; // Don't insert null or control characters as they can result in // unexpected behaviour if (ch < ' ') return false; #if !defined(OS_WIN) // Don't insert ASCII character if ctrl w/o alt or meta is on. // On Mac, we should ignore events when meta is on (Command-<x>). if (ch < 0x80) { if (evt->keyEvent()->ctrlKey() && !evt->keyEvent()->altKey()) return false; #if defined(OS_MACOSX) if (evt->keyEvent()->metaKey()) return false; #endif } #endif } if (!frame->editor()->canEdit()) return false; return frame->editor()->insertText(evt->keyEvent()->text(), evt); ... And gtk implementation of WebInputEventFactory::keyboardEvent() (webkit/api/src/gtk/WebInputEventFactory.cpp, line 225): ... // This should set text to 0 when it's not a real character. // FIXME: fix for non BMP chars // TODO(james.su@gmail.com): // Support control characters input like Windows. // See: http://en.wikipedia.org/wiki/Control_characters result.unmodifiedText[0] = result.text[0] = static_cast<WebUChar>(gdk_keyval_to_unicode(event->keyval)); ... You can see that, on Linux, the text of a keyboard event is set to the unicode char corresponding to |event->keyval| which might be greater than 0x80 when using a non-English keyboard layout, even when ctrl key is pressed. In EditorClientImpl::handleEditKeyboardEvent(), the character will be inserted as text if ch >= 0x80, no matter if ctrl is pressed or not. That's why when using some non-English keyboard layout (eg. Russian), some unexpected characters will be input when press accelerator keys such as ctrl-l. On Windows, ctrl key combinations will generate control characters, see: http://en.wikipedia.org/wiki/Control_characters for details, especially the "How control characters map to keyboards" section. So rather than patching EditorClientImpl::handleEditingKeyboardEvent() to filter out such unexpected inputs, I choose to emulate the control characters behavior of Windows, to make sure no key event with ch >= 0x80 will be generated when ctrl is pressed. This approach not only fixes issue 21471, but also makes the behavior on Linux similar than on Windows. For EditorClientImpl::handleEditKeyboardEvent(), we might need to revise the logic of event filter to see if it has any other potential issues. But I think we can address it separately. BUG=21471 : REGRESSION: Ctrl+F results in "а" added to the edit box in belarusian TEST=Switch keyboard layout to Russian or Belarusian, press ctrl-f in any edit box in a web page, search box should be opened and nothing should be input into the edit box.

Patch Set 1 #

Total comments: 4

Patch Set 2 : '' #

Unified diffs Side-by-side diffs Delta from patch set Stats (+59 lines, -15 lines) Patch
M webkit/api/src/gtk/WebInputEventFactory.cpp View 1 2 chunks +59 lines, -15 lines 0 comments Download

Messages

Total messages: 20 (0 generated)
James Su
Please help review. Regards James Su
11 years, 3 months ago (2009-09-11 11:48:18 UTC) #1
darin (slow to review)
just some style nits... i didn't review for substance. http://codereview.chromium.org/195062/diff/1/2 File webkit/api/src/gtk/WebInputEventFactory.cpp (right): http://codereview.chromium.org/195062/diff/1/2#newcode186 Line ...
11 years, 3 months ago (2009-09-11 17:36:43 UTC) #2
Hironori Bono
Hi James, Thank you for your change, but, unfortunately, I totally disagree with this change. ...
11 years, 3 months ago (2009-09-12 20:26:13 UTC) #3
James Su
Hi hbono, Thanks a lot for your valuable feedback. But I'm wondering if you have ...
11 years, 3 months ago (2009-09-13 06:10:40 UTC) #4
Hironori Bono
Hi James, > Thanks a lot for your valuable feedback. But I'm wondering if you ...
11 years, 3 months ago (2009-09-14 01:06:47 UTC) #5
James Su
On 2009/09/14 01:06:47, hbono wrote: > Hi James, > > > Thanks a lot for ...
11 years, 3 months ago (2009-09-14 03:33:41 UTC) #6
James Su
Thanks for your feedback. CL just updated. Regards James Su On 2009/09/11 17:36:43, darin wrote: ...
11 years, 3 months ago (2009-09-14 03:59:44 UTC) #7
James Su
http://codereview.chromium.org/195062/diff/1/2 File webkit/api/src/gtk/WebInputEventFactory.cpp (right): http://codereview.chromium.org/195062/diff/1/2#newcode186 Line 186: case WebCore::VKEY_2: return 0; On 2009/09/11 17:36:43, darin ...
11 years, 3 months ago (2009-09-14 04:00:28 UTC) #8
Hironori Bono
Hi James, On 2009/09/14 03:33:41, James Su wrote: > I don't think it's a regression ...
11 years, 3 months ago (2009-09-14 04:12:02 UTC) #9
Hironori Bono
Hi James, Sorry for my stupid comments. I don't have any intention to play a ...
11 years, 3 months ago (2009-09-14 04:30:52 UTC) #10
James Su
Hi hbono, If you have any concrete reasons and evidence for your objection to this ...
11 years, 3 months ago (2009-09-14 05:04:35 UTC) #11
James Su
ping.
11 years, 3 months ago (2009-09-16 23:20:38 UTC) #12
James Su
ping again :-)
11 years, 3 months ago (2009-09-19 00:10:56 UTC) #13
Evan Martin
Yo James, Sorry for ignoring your changes. It would help if you pinged someone specifically, ...
11 years, 3 months ago (2009-09-21 18:54:50 UTC) #14
James Su
Thanks for your suggestion. I'll ping you directly next time :-D Regards James Su On ...
11 years, 3 months ago (2009-09-22 00:41:20 UTC) #15
James Su
Hi, I just checked the issue raised by hbono that on Windows, the vkey value ...
11 years, 2 months ago (2009-10-13 02:23:31 UTC) #16
Hironori Bono
I don't have any objections against this code. By the way, this change reminds me ...
11 years, 2 months ago (2009-10-13 03:41:43 UTC) #17
James Su
On 2009/10/13 03:41:43, hbono wrote: > I don't have any objections against this code. > ...
11 years, 2 months ago (2009-10-13 09:15:28 UTC) #18
James Su
And Safari has the same behavior like IE on both Windows and Mac. On 2009/10/13 ...
11 years, 2 months ago (2009-10-13 09:24:50 UTC) #19
Evan Martin
11 years, 2 months ago (2009-10-16 00:57:17 UTC) #20
LGTM

Powered by Google App Engine
This is Rietveld 408576698