Bug 76583 – After NPP_HandleEvent returns true (I handled it), WebKit then processes the command-key anyway

• Component: Plug-ins
• Status: RESOLVED WONTFIX

[Rudi Sherry]

NPP_HandleEvent() is documented as returning 'true' if the plug-in handles the event.  Presumably this means the browser will then do nothing else with it.

For Command-P and Command-Q (and, I believe, any other command that has a menu equivalent) this is not true.  Our plug-in returns 'true' for that key-down (and in fact every event we are given), but Safari then goes ahead and puts up its own Print sheet or Quits.

It should trust that the plug-in handled it, whatever it did.

[Rudi Sherry]

I found where the issue is: in NetscapePlugin::platformHandleKeyboardEvent() it ignores the return value of NPP_HandleEvent(), with this comment:


    // Most plug-ins simply return true for all keyboard events, even those that aren't handled.
    // This leads to bugs such as <rdar://problem/8740926>. We work around this by returning false
    // if the keyboard event has the command modifier pressed.
    // However, for command-A (the shortcurt for 'Select All' we will always return true, since we don't
    // want the entire page to be selected if the focus is in a plug-in text field (see <rdar://problem/9309903>).

[Rudi Sherry]

So this is related to bug 8740926 and bug 9309903 (added this comment for easy links to those bugs)

[Rudi Sherry]

Entered as <rdar://problem/11133013>

[Rudi Sherry]

Any traction on this?  We're getting complaints on our forum that Command-F shows both our 'Find' and Safari's 'Find'.

[Alexey Proskuryakov]

Mass closing plug-in bugs, as plug-in support has been removed from WebKit.

Please comment and/or reopen if this still affects WebKit in some way.