Hi Petr,
Looks fine to me, thanks for fixing this.
One comment - perhaps it'd be better to synthesize one UP event.
According to the spec, the Plugin doesn't receive DOWN/UP events
associated with composition - the Plugin receive one DOWN event and
returns kNPEventStartIME to start composition and we should probably
synthesize one UP event for consistency.
And it seems like Glass works the same way - synthesize one UP event
associated with composition:
GlassEmbeddedWindow+Npapi.m (_1dispatchCocoaNpapiTextInputEvent function)
if ([chars length] == 1) {
Java_com_sun_glass_events_mac_NpapiEvent__1dispatchCocoaNpapiKeyEvent(
env, jNpapiClass, jPtr,
com_sun_glass_events_mac_NpapiEvent_NPCocoaEventKeyUp,
0, jText, jText, JNI_FALSE, 0, JNI_FALSE);
}
Dmitry
Petr Pchelko wrote:
Hello, AWT team.
Please review the fix for the following issue:
http://bugs.sun.com/view_bug.do?bug_id=8010009
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8010009/webrev.00/
<http://cr.openjdk.java.net/%7Epchelko/8010009/webrev.00/>
The problem occurred because we use input methods for plugin keyboard
input. So when the text from the input method comes only KEY_TYPED
events were synthesized. Now we also synthesize KEY_RELEASED events.
Additionally, the last keyCode should be stored because some swing
code relies on the keyCode for the KEY_RELEASED event.
There still are 2 issues around this:
1. Firefox has a very strange behavior when user types extremely fast.
KeyReleased events come from the browser, while they should not
according to the NPAPI specification. I suppose it is a bug in
Firefox. I did not add any workaround for this issue, because I there
is no way to add it safely. The workaround could possible break the
existing code. So I suppose it is better to file a bug to Mozilla.
2. The game from Pogo does not expect some possible combinations of
events coming and skips squares if you type for example " 'r " .
This should probably be filed to Pogo Games.
With best regards. Petr.
