United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6637607 1st char. is discarded after a modal dialogue shows up and disappears
JDK-6637607 : 1st char. is discarded after a modal dialogue shows up and disappears

Details
Type:
Bug
Submit Date:
2007-12-05
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
client-libs
OS:
windows_vista,windows_xp
Sub-Component:
java.awt
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,7
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

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
EVALUATION

It seems there was another similar change request about this problem, but I can't find it. Looks like a focus-related issue.
                                     
2007-12-17
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.
                                     
2007-12-19
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 ###@###.###
                                     
2008-03-26



Hardware and Software, Engineered to Work Together