Pass unhandled keyup messages coming in from the renderer to the underlying view. This is needed

for system keyboard messages which are generated when the Alt key is pressed in addition to other
keys to function correctly in ChromeFrame.

The TabContentsView implementation for windows does the right thing by specifically checking for keydown
events before processing them as accelerators. The TabContentsView implementation for Linux also treated
keyup messages as accelerators, which is now fixed.

This fixes parts of http://code.google.com/p/chromium/issues/detail?id=22996

Bug=22996

Review URL: http://codereview.chromium.org/255028

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27926 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 1 insertions, 8 deletions

diff --git a/chrome/browser/renderer_host/render_view_host.cc b/chrome/browser/renderer_host/render_view_host.cc
index a778f62..e793a7b 100644
--- a/chrome/browser/renderer_host/render_view_host.cc
+++ b/chrome/browser/renderer_host/render_view_host.cc
@@ -1436,14 +1436,7 @@ void RenderViewHost::UnhandledKeyboardEvent(
     const NativeWebKeyboardEvent& event) {
   RenderViewHostDelegate::View* view = delegate_->GetViewDelegate();
   if (view) {
-    // TODO(brettw) why do we have to filter these types of events here. Can't
-    // the renderer just send us the ones we care abount, or maybe the view
-    // should be able to decide which ones it wants or not?
-    if ((event.type == WebInputEvent::RawKeyDown) ||
-        (event.type == WebInputEvent::KeyDown) ||
-        (event.type == WebInputEvent::Char)) {
-      view->HandleKeyboardEvent(event);
-    }
+    view->HandleKeyboardEvent(event);
   }
 }