NPAPI:CocoaCompositionClarification: Difference between revisions
No edit summary |
|||
| Line 15: | Line 15: | ||
= Specification Change = | = Specification Change = | ||
The specification currently states, in the "Text Input" section: | |||
"During complex text input the browser will continue to send regular key events. So long as the plugin still wants complex text input (which may result in a NPCocoaEventTextInput event being sent) it should continue to return kNPEventStartIME for NPCocoaEventKeyDown. If a plugin returns anything other than kNPEventStartIME for NPCocoaEventKeyDown then complex text input will be canceled." | |||
This paragraph will be changed to: | |||
"No <code>NPCocoaEventKeyDown</code> or <code>NPCocoaEventKeyUp</code> events associated with a complex text input window that may be open during composition will be sent to the plugin. <code>NPCocoaEventFlagsChanged</code> events will still be sent. Browser implementers should be mindful of the edge case where a key down ends composition (typically the <code>return</code> key) - the subsequent key up event, while it may not target the input window directly, is considered to be associated with the input window and should not be sent to the plugin." | |||
= Open Questions = | = Open Questions = | ||
Revision as of 19:19, 6 January 2011
Status
Under consideration.
Contributors
- Last modified: January 6, 2011
- Authors: Josh Aas (Mozilla)
- Contributors: Stuart Morgan (Google)
Overview
This proposal modifies the existing Cocoa NPAPI specification (NPAPI:CocoaEventModel). Under the current specification plugins receive key events during complex text composition but do not have a reliable way to know whether or not key events are intended for use in the composition. Since composition can be canceled by the user or the browser plugins cannot assume that composition is in progress until they receive an 'NPCocoaEventTextInput' event.
Specification Change
The specification currently states, in the "Text Input" section:
"During complex text input the browser will continue to send regular key events. So long as the plugin still wants complex text input (which may result in a NPCocoaEventTextInput event being sent) it should continue to return kNPEventStartIME for NPCocoaEventKeyDown. If a plugin returns anything other than kNPEventStartIME for NPCocoaEventKeyDown then complex text input will be canceled."
This paragraph will be changed to:
"No NPCocoaEventKeyDown or NPCocoaEventKeyUp events associated with a complex text input window that may be open during composition will be sent to the plugin. NPCocoaEventFlagsChanged events will still be sent. Browser implementers should be mindful of the edge case where a key down ends composition (typically the return key) - the subsequent key up event, while it may not target the input window directly, is considered to be associated with the input window and should not be sent to the plugin."
Open Questions
- None
Alternatives
Preserved for reference...
- Once composition is started it will always result in an 'NPCocoaEventTextInput' event and canceled compositions will simply result in an 'NPCocoaEventTextInput' event with an empty string. Unlike the currently proposed solution this has the downside of potential backwards-compatibility issues. Adobe Flash?
- In order to provide the plugin with information about whether or not there is a complex text composition in progress we will bump the 'NPCocoaEvent' version to '2'. If a plugin receives an 'NPCocoaEvent' with a version of '2' or higher then the key structure will contain a field of type 'NPBool' called 'compositionInProgress'. The 'compositionInProgress' field is only valid for 'NPCocoaEventKeyDown' events. It will be set to false when no composition is in progress and true when a composition is in progress.