Updates:
Cc: [email protected] [email protected]
Comment #21 on issue 11480 by [email protected]: Support GTK keyboard
themes (emacs keybindings)
http://code.google.com/p/chromium/issues/detail?id=11480
Though I had committed the CL for fixing this issue, as mentioned in the
description,
there is still an issue on DOM accesskey handling:
Known issue:
If a key event matches not only a system defined key binding but also an
accesskey of
a DOM element, then both corresponding edit commands and accesskey action
will be
executed. Because accesskey is handled in WebViewImpl::CharEvent(), while
edit
commands are bound to RawKeyDown or KeyUp events.
To understand the reason of this issue, you may see the code of
WebViewImpl::KeyEvent():
...
if (handler->keyEvent(evt)) {
if (WebInputEvent::RawKeyDown == event.type && !evt.isSystemKey())
suppress_next_keypress_event_ = true;
return true;
}
...
You can see that if a RawKeyDown event is marked as a SystemKey, then its
keypress
event won't be suppressed no matter if it's handled or not. On Linux,
accesskey's
modifier is Alt and a key event with Alt down is marked as a SystemKey,
thus when an
alt key binding is pressed and if it happens to be a system defined key
binding, then
the issue described above will occur.
Now the question is, why we don't suppress the keypress event of a
RawKeyDown event
which is marked as a SystemKey?
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
