<AWT Dev> [8] Review request for 7156194 [macosx] Can't type non-ASCII characters into applets

Dmitry Cherepanov dmitry.cherepanov at oracle.com
Tue Apr 10 03:18:49 PDT 2012


Hi Anthony,

Anthony Petrov wrote:
> Hi Dmitry,
>
> On 4/5/2012 11:47 AM, Dmitry Cherepanov wrote:
>>> src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
>>>>  188             while (index < length) {
>>>>  189                 c = text.charAt(index);
>>>>  190                 peer.dispatchKeyEvent(KeyEvent.KEY_TYPED,
>>>>  191                                       System.currentTimeMillis(),
>>>>  192                                       0, 
>>>> KeyEvent.VK_UNDEFINED, c,
>>>>  193                                       
>>>> KeyEvent.KEY_LOCATION_UNKNOWN);
>>>>  194                 index++;
>>>>  195             }
>>>
>>> Are we sure we want to dispatch each character for the 
>>> handleInputEvent(String) event with its own timestamp? Does a 
>>> browser combine several unrelated key strokes into a single 
>>> InputEvent, or are all the characters actually represent one 
>>> integral input event? Put another way, should user code be able to 
>>> see that a bunch of TYPED events actually belongs to one native 
>>> input event?
>>
>> I'm not sure that I understood your question correctly. When a 
>> browser starts a complex text composition, the Plug-in doesn't 
>> receive KeyDown/KeyUp events but it receives TextInput event 
>> containing the composed string and this TextInput event is sent when 
>> the composition is finished. If this doesn't answer your question, 
>> could you please give an example?
>
> At line 191 in the above quote you're assigning a new timestamp to 
> every Java TYPED event, while all the characters sent via the TYPED 
> events actually belong to just one browser's InputEvent. I'm wondering 
> whether all these TYPED events should share the same timestamp (e.g. 
> acquired before entering the while loop) or not. Could you 
> investigate/clarify this please?

Both ways seems to be fine to me because the plug-in doesn't receive any 
TextInput events during 'in-progress' text composition and receives the 
TextInput event when the text composition is done. If you think that 
there should be some kind of consistency in it, I guess that its okay to 
have these TYPED events with the same timestamp but I don't see any 
reason why it should matter.

Thanks,
Dmitry





More information about the awt-dev mailing list