JDK-6637607 : 1st char. is discarded after a modal dialogue shows up and disappears
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2007-12-05
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6 JDK 7
5.0u17-revFixed 5.0u18Fixed 6u10Fixed 7 b27Fixed
Related Reports
Duplicate :  
JDK-6668883 - First character does not show in JTextArea when tabbed in from another JTextArea
Relates :  
JDK-6986252 - java/awt/Focus/ConsumeNextKeyTypedOnModalShowTest/ConsumeNextKeyTypedOnModalShowTest.java faled
Description
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
Comments
SUGGESTED FIX src/windows/native/sun/windows/awt_Component.cpp src/share/classes/java/awt/DefaultKeyboardFocusManager.java _______________________________________________________________________ ------- awt_Component.cpp ------- *** /tmp/sccs.SgdS3V Wed Jan 16 15:29:06 2008 --- awt_Component.cpp Wed Jan 16 11:28:15 2008 *************** *** 5715,5724 **** --- 5715,5727 ---- keyDownConsumed = (id == java_awt_event_KeyEvent_KEY_PRESSED); env->DeleteGlobalRef(self); env->DeleteGlobalRef(event); delete nhes; return; + + } else if (id == java_awt_event_KeyEvent_KEY_PRESSED) { + keyDownConsumed = FALSE; } /* Consume a KEY_TYPED event if a KEY_PRESSED had been, to support * the old model. */ _______________________________________________________________________ ------- DefaultKeyboardFocusManager.java ------- *** /tmp/sccs.IzXoy4 Wed Jan 16 15:29:06 2008 --- DefaultKeyboardFocusManager.java Wed Jan 16 15:17:21 2008 *************** *** 1077,1086 **** --- 1077,1089 ---- consumeTraversalKey(e); if (contains) { focusNextComponent(focusedComponent); } return; + } else if (e.getID() == KeyEvent.KEY_PRESSED) { + // Fix for 6637607: consumeNextKeyTyped should be reset. + consumeNextKeyTyped = false; } toTest = focusedComponent.getFocusTraversalKeys( KeyboardFocusManager.BACKWARD_TRAVERSAL_KEYS); contains = toTest.contains(stroke); *** (#1 of 1): 2008-03-26 10:20:32 MSK ###@###.###
26-03-2008
EVALUATION 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.
19-12-2007
EVALUATION It seems there was another similar change request about this problem, but I can't find it. Looks like a focus-related issue.
17-12-2007