© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
A proposed API change (NPAPI version 0.20):
1. Per default, no plug-in gets any keyboard events. Windowless plug-ins just don't get them passed through; and for windowed plug-ins, we install hooks to filter them out (on Win32 with SetWindowsHookE
2. The name NPPVpluginKeybo
3. When a plug-in's library is loaded, we query it for that new name through the static NP_GetValue . To participate in the key handling contract, the plug-in _must_ return the value 0x100 (for version 1.00).
4. Plug-ins participating in the contract get (almost) all keyboard events passed through NP_HandleEvent. They _must_ however return FALSE when the key event wasn't needed (this includes the Tab key, when the last/first tabbable element was reached so that the browser can correctly tab out of the plug-in). Plug-ins incorrectly participating in the contract might get blacklisted over time.
5. The plug-in never receives any keyboard events associated with the F6 key. F6 currently moves the focus between the address bar, the sidebar and all content frames. Hitting F6 when a plug-in is focused should eventually behave the same as hitting F6 when a text field is focused.
This proposal is backwards compatible with all existing plug-ins. Existing plug-ins won't however be keyboard accessible anymore. New plug-ins can optionally get back all of the desired functionality (if they really need it), offering the keyboard user a much better experience. Non-compliant plug-ins can at least be escaped through F6.
Alternative: A slightly more conservative proposal would consist in filtering out only events related to the F6 keys and letting non-participating plug-ins handle all other keyboard events on their own. This might however not be enough of an incentive to plug-in authors for cooperating in future versions.