DescriptionSupports 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 : '' #Messages
Total messages: 20 (0 generated)
|