When a modal dialogue appears and disappears, user inputs some char. string to text field.
The 1st char. of the string can not be input. That seems discarded.

REPRODUCE : 
The same instruction is mentioned the windows which shows up when the test program is invoked.

1) Invoke the attached test program
2) Press "TAB" key
  A dialogue with "ok" button  will show up.
3) Click the "ok"
  The dialogue disappears and focus moves to the text field in the window.
4) Type "abc" You will see only "bc" in the text field.

CONFIGURATION:
 JDK : 7b24(amd64), 6u4(amd64), 5.0u14(amd64) and 1.4.2_16(i586)
 OS  : Windows Vista Ultimate(Japanese)
 CPU : Core 2 Duo
Posted Date : 2007-12-05 05:03:46.0

N/A

It seems there was another similar change request about this problem, but I can't find it. Looks like a focus-related issue.
Posted Date : 2007-12-17 09:01:17.0

Here's the problem. When I prees TAB in the first textfield an appropriate KEY_PRESSED
event is generated. It then gets handled in the AWTEventListener set by the testcase.
On receiving the event the listener shows a modal dialog that in its turn starts
a new event pump. The other two key events following by the TAB press are KEY_TYPED and
KEY_RELEASED. These events are dispatched on the new event pump. I.e. they are dispatched
_before_ the first KEY_PRESSED event processing is completed. After the modal dialog
is closed the processing of the KEY_PRESSED event continues (all this takes place in
the Component.dispatchEventImpl() method). It in turn sets "consumeNextKeyTyped" to
true (see the DKFM.processKeyEvent() method), consumes the event itself and passes it
to the native code. There it also (!) sets similar native field "keyDownConsumed" to
true.
Thus the problem is that while processing KEY_PRESSED event it's not taken into
account that following KEY_TYPED/KEY_RELEASED events may be processed "too early"
and that further actions will affect absolutely different KEY_TYPED event.
Posted Date : 2007-12-19 17:10:59.0