Always report keypresses in plugins as handled on the Mac

This matches the behavior of other Mac browsers; until the new Advanced Key Handling spec is implemented by plugins and Chromium, the return value for key events can't be trusted to be meaningful.

BUG=42490
TEST=Typing should still work in plugins. Pressing delete in a Silverlight text field shouldn't go back in history.

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

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

1 files changed, 11 insertions, 4 deletions

diff --git a/webkit/glue/plugins/webplugin_delegate_impl_mac.mm b/webkit/glue/plugins/webplugin_delegate_impl_mac.mm
index e0f479e..ce09fdb 100644
--- a/webkit/glue/plugins/webplugin_delegate_impl_mac.mm
+++ b/webkit/glue/plugins/webplugin_delegate_impl_mac.mm
@@ -620,12 +620,19 @@ bool WebPluginDelegateImpl::PlatformHandleInputEvent(
   }
   bool handled = instance()->NPP_HandleEvent(plugin_event) != 0;
 
+  // Plugins don't give accurate information about whether or not they handled
+  // events, so browsers on the Mac ignore the return value.
+  // Scroll events are the exception, since the Cocoa spec defines a meaning
+  // for the return value.
   if (WebInputEvent::isMouseEventType(event.type)) {
-    // Plugins are not good about giving accurate information about whether or
-    // not they handled events, and other browsers on the Mac generally ignore
-    // the return value. We may need to expand this to other input types, but
-    // we'll need to be careful about things like Command-keys.
     handled = true;
+  } else if (WebInputEvent::isKeyboardEventType(event.type)) {
+    // For Command-key events, trust the return value since eating all menu
+    // shortcuts is not ideal.
+    // TODO(stuartmorgan): Implement the advanced key handling spec, and trust
+    // trust the key event return value from plugins that implement it.
+    if (!(event.modifiers & WebInputEvent::MetaKey))
+      handled = true;
   }
 
   return handled;