| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Review URL: http://codereview.chromium.org/195062
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29261 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes some initialization order, removes unused varibles,
and fixes a couple signed/unsigned comparison errors. Please
check the signed/unsigned cases.
We can't enable it for windows yet because MSVC complains
about headers pulled in from WebCore. We'll have to wait
until the API is upstreamed.
BUG=21140
Review URL: http://codereview.chromium.org/214024
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26728 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, SandboxIPCProcess had to be a full WebKitClient because of
the following assertion failure:
0 0x08af0a77 in buildBaseTextCodecMaps ()
at
third_party/WebKit/WebCore/platform/text/TextEncodingRegistry.cpp:176
1 0x08af0e73 in WebCore::atomicCanonicalTextEncodingName
(name=0x985d665 "UTF-8")
at
third_party/WebKit/WebCore/platform/text/TextEncodingRegistry.cpp:241
2 0x08aee811 in TextEncoding (this=0xb876ef8, name=0x985d665 "UTF-8")
at third_party/WebKit/WebCore/platform/text/TextEncoding.cpp:61
3 0x08aee88a in WebCore::UTF8Encoding ()
at third_party/WebKit/WebCore/platform/text/TextEncoding.cpp:266
4 0x08ae744c in WebCore::String::fromUTF8 (string=0x56d7a120
"�226\207�211�233正�221",
size=15) at third_party/WebKit/WebCore/platform/text/String.cpp:674
5 0x0872a7c0 in WebKit::WebString::fromUTF8 (data=0x56d7a120
"�226\207�211�233正�221",
length=15) at webkit/api/src/WebString.cpp:72
6 0x087245bd in WebKit::WebFontInfo::familyForChars
(characters=0x56c11628, numCharacters=1)
at webkit/api/src/gtk/WebFontInfo.cpp:98
7 0x0847599a in SandboxIPCProcess::HandleGetFontFamilyForChars
(this=0xff869ba8, fd=29,
pickle=@0xff86900c, iter=0xff869054, fds=@0xff86901c)
at chrome/browser/renderer_host/render_sandbox_host_linux.cc:215
8 0x08475d70 in SandboxIPCProcess::HandleRequestFromRenderer
(this=0xff869ba8, fd=29)
at chrome/browser/renderer_host/render_sandbox_host_linux.cc:115
9 0x08475fea in SandboxIPCProcess::Run (this=0xff869ba8)
at chrome/browser/renderer_host/render_sandbox_host_linux.cc:84
10 0x084747f9 in RenderSandboxHostLinux (this=0x56c10e78)
at chrome/browser/renderer_host/render_sandbox_host_linux.cc:299
This this patch, we remove the need to use WebString and the codec
translation (which was just a translation from UTF8 to UTF16 and back
again anyway) and thus can remove all of the WebKitClient gubbins.
BUG=17260
http://codereview.chromium.org/164112
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23050 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handled in original code are addressed, for example the input method in password
box case.
The most important change in this CL is the change to key event processing flow.
In old code, a key event will first be sent to webkit then dispatched to IME
for filtering. With this CL, a key event will first be dispatched to IME for
filtering, then how to send the event to webkit is decided by the filtering
result.
This CL tries to emulate the keyboard input behavior on Windows as much as
possible. For example, if a keydown event is filtered by IME, then its virtual
key code will be changed to VK_PROCESSKEY(0xE5) to prevent webkit from
processing it again. This behavior can workaround bug 16281.
To test this CL, you may cut and save following html code into a file and open
it in chrome.
------------------8<----cut here----->8---------------------
<html><head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<script>
function keyEventHandler(event) {
var props = [ "type", "charCode", "keyCode", "altKey",
"ctrlKey", "shiftKey", "metaKey" ];
var info = document.getElementById('info');
var s = '';
for (var i in props) {
s += props[i] + ':' + event[props[i]] + ' ';
}
info.value += s + '\n';
}
function textEventHandler(event) {
info.value += "type:" + event['type'] + " data:" + event['data'] + '\n';
}
function passwordChangeEventHandler(event) {
var input2 = document.getElementById('input2');
info.value += "password:" + input2.value + '\n';
}
function onLoad() {
var input = document.getElementById('input');
input.addEventListener('keydown', keyEventHandler, false);
input.addEventListener('keyup', keyEventHandler, false);
input.addEventListener('keypress', keyEventHandler, false);
input.addEventListener('textInput', textEventHandler, false);
var input2 = document.getElementById('input2');
input2.addEventListener('change', passwordChangeEventHandler, false);
}
</script>
</head><body onload="onLoad()">
<input id="input" size="20">
<input id="input2" type="password" size="20">
<p>
<textarea id="info" rows="40" cols="150"></textarea>
</p></body></html>
------------------8<----cut here----->8---------------------
This CL was confirmed to fix following issues:
BUG=16281 "arrow keys and backspace/delete keys move/delete two characters at a
time when xim immodule is used"
BUG=16282 "Disable IMEs in a password input"
BUG=16596 "fcitx (chinese input method) not working in ubuntu 9.04"
BUG=16659 "Crash near RenderWidgetHostViewGtk::IMEUpdateStatus"
BUG=16699 "Can't move cursor to omnibox and use input method if cursor is
currently in a text input box in web page."
BUG=16796 "Input method issue: When inputting text in a text box, if there is a
composition string then pressing Backspace or Delete will cause the composition
string be cleared and the text box refuses to accept any further input.
All tests assume above html code is used.
TEST=Start scim with "scim -d" and start chrome with GTK_IM_MODULE=xim and
XMODIFIERS=@im=SCIM. Type something in input box, eg. "hello", then press
backspace, to see if only one character is deleted.
TEST=Move cursor to password input box, press ctrl-space to see if input method
is not activated. Switch keyboard layout to Canadian-French then type a'[{' key
and an 'a' key, then press enter, to see if a Latin character "U+00E2" is
inputted in password box.
TEST=Install fcitx with "sudo apt-get install fcitx" (assume you are using
Ubuntu/Debian). Open a terminal, export XMODIFIERS=@im=fcitx and
GTK_IM_MODULE=xim then run fcitx, then start chrome. Move cursor into an input
box, press ctrl-space and input something, eg. "nihao" then press space. Check
if some Chinese characters are inputted.
TEST=Start chrome with GTK_IM_MODULE=scim. Move cursor into a text input box
then move into a password box, chrome should not crash.
TEST=Move cursor into a text input box, then click omnibox, and see if the text
input box has lost focus. Press ctrl-space to activate input method, then type
something, and see of the input goes into omnibox.
TEST=Move cursor into a text input box and enable a Chinese Pinyin input method,
then type something, eg. "dajiahao", make sure a composition string is displayed
in the text input box, then press backspace and see if there is still a
composition string and backspace is handled by input method.
patch by James Su <james.su [at] gmail>
original review URL: <http://codereview.chromium.org/149755>
Review URL: http://codereview.chromium.org/155869
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21203 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
| |
Fontconfig will return fonts which are unreadable to the current
process if the system cache contains them.
BUG=16715
http://codereview.chromium.org/149628
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20663 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
Fontconfig cannot filter out non-scalable fonts on Hardy.
http://codereview.chromium.org/149482
BUG=16411
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20604 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
After a discussion in <http://crbug.com/15852>, I noticed I wrongly understood the Dvorak and European keyboards. We should not use US layout for handling shortcut keys. To fix this problem, this change uses |event->hardware_keycode| only when WebKit::windowsKeyCodeForKeyEvent() returns 0. When we use the Hebrew (or Russian) layout, |event->keyval| becomes GDK_hebrew_* (or GDK_Cyrillic_*) and this function returns 0.)
BUG=15852 "Incorrect keycode with dvorak keyboard layout on Linux"
TEST=Open <http://www.asquare.net/javascript/tests/KeyCode.html>, press 'x' of a dvorak keyboard, and its keyDown.keyCode becomes 88.
Review URL: http://codereview.chromium.org/149248
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20369 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were filtering out non-scalable fonts /after/ the fact.
This patch changes it so that we specify to fontconfig that it
shouldn't return non-scalable fonts to us.
We also duplicate this code into WebFontInfo so that we don't get
these issues when performing glyph-fallback.
http://codereview.chromium.org/149437
BUG=16403
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20351 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue is caused by my another mistake that I forgot setting the modifier-key state in creating a Char event in RenderWidgetHostViewGtkWidget::ForwardCharEvent().
Since the GtkIMContext signal-handlers don't use GdkEventKey objects and cannot get the modififer-key state, this change save the state in RenderWidgetHostViewGtkWidget::KeyPressReleaseEvent() before dispatching a key event to the GtkIMContext object.
Also, this change adds gtk_im_context_focus_in() and gtk_im_context_focus_out() calls to fix compatibility problems with ibus.
BUG=10953 "IME support"
BUG=15531 "regression: shift-space doesn't scroll the page backwards"
TEST=Open a test page in <http://crbug.com/15531>, press shift+space keys, and observe ev.shiftKey is true.
Review URL: http://codereview.chromium.org/151010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19707 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is hopefully the last step before our renderers can run cleanly
in a chroot.
WebKit needs to be able to ask for the correct font to use in the case
that the current font doesn't include glyphs for certain code points.
Currently we make a fontconfig call in our WebKit port to handle this.
This patch changes this so that the call is sent our via
ChromiumBridge. Since we are at ChromiumBridge, we could make a sync
IPC to the browser. However, fontconfig is a single threaded library
and we are already using it on the UI thread in the browser, so the
sync IPC would have to terminate on the UI thread. Even if this
doesn't deadlock, it causes huge spikes in latency.
So, instead, we send the IPC to the sandbox host process which is
already setup to handle fontconfig requests from Skia. See:
http://code.google.com/p/chromium/wiki/LinuxSandboxIPC
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19287 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is an updated version of <http://codereview.chromium.org/126118> that I reverted because of issue 15024 <http://crbug.com/15024>. This issue 15024 is caused by my bonehead mistake that I forgot handling the case that gtk_im_context_filter_keypress() returns false. (The GtkIMContext usually returns false when we type control keys, such as return, page up, page down, etc.) To handle this case, this change added code that manually creates a Char
event and send it to the renderer in RenderWidgetHostViewGtkWidget::KeyPressReleaseEvent(). Except this code, it is exactly the same as <http://codereview.chromium.org/126118>.
Unfortunately, this change still uses std::wstring, I'm going to send another change which replace std::wstring with string16.
(The following message is copied from <http://codereview.chromium.org/126118>.)
This change implements signal handers of the GtkIMContext object to support IMEs anddead-keys. Also, to improve compatibility with Windows Chrome, this changeemulates IPC messages sent on Windows when we input characters and fixes
Issue13604 as well as Issue 10953 and 11226. Even though I notice we need more workfor fixing edge cases (e.g. disabling IMEs on a password input) on Linux, Ithink this is the good starting point. (Supporting edge-cases requirescomplicated code and it makes hard to review.)
BUG=10953 "IME support"
BUG=11226 "Dead keys and accents input not working"
BUG=13604 "Hotkeys not working in non-us keyboard layout"
BUG=13711 "Alt-D does not work when in editbox"
TEST=Open a web page which contains an <input> form, type a '[{' key and an 'A' key on a Canadian-French keyboard, and see a Latin character "U+00E2" is displayed in the <input> form.
TEST=Open a web page which contains an <input> form, enable an Chinese Pinyin IME, type a 'W' key, type an 'O' key, and see a Chinese character is displayed in the <input> form.
TEST=Change the keyboard layout to Hebrew (or Russian), open a web page which contains an <input> form, input some characters in the <input> form, type control+a, and see the text in the <input> form is selected.
TEST=Open a web page which contains a <textarea> form, type a return key, and see a new line is inserted.
Review URL: http://codereview.chromium.org/147011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19238 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
| |
TBR=evan
BUG=10953 "IME support"
BUG=11226 "Dead keys and accents input not working"
BUG=13604 "Hotkeys not working in non-us keyboard layout"
TEST=none
Review URL: http://codereview.chromium.org/147010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19015 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
implements signal handers of the GtkIMContext object to support IMEs and dead-keys. Also, to improve compatibility with Windows Chrome, this change emulates IPC messages sent on Windows when we input characters and fixes Issue 13604 as well as Issue 10953 and 11226. Even though I notice we need more work for fixing edge cases (e.g. disabling IMEs on a password input) on Linux, I think this is the good starting point. (Supporting edge-cases requires complicated code and it makes hard to review.)
BUG=10953 "IME support"
BUG=11226 "Dead keys and accents input not working"
BUG=13604 "Hotkeys not working in non-us keyboard layout"
TEST=Open a web page which contains an <input> form (e.g. <http://www.google.com/>), type a '[{' key and an 'A' key on a Canadian-French keyboard, and see a Latin character "U+00E2" is displayed in the <input> form.
TEST=Open a web page which contains an <input> form (e.g. <http://www.google.com/>), enable an Chinese Pinyin IME, type a 'W' key, type an 'O' key, and see a Chinese character is displayed in the <input> form.
TEST=Change the keyboard layout to Hebrew (or Russian), open a web page which contains an <input> form, input some characters in the <input> form, type control+a, and see the text in the <input> form is selected.
Review URL: http://codereview.chromium.org/126118
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19009 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
communication between WebPlugin and WebPluginDelegate, to use a cross-platform
message based on WebInputEvent.
BUG=8202
TEST=A lot of manual testing on Linux and Windows, with Flash plugins and a
custom plugin that dumps events on Linux.
Review URL: http://codereview.chromium.org/115330
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16692 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/99104
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15877 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
R=dglazkov
Review URL: http://codereview.chromium.org/113186
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15739 0039d316-1c4b-4281-b951-d872f2087c98
|
