JDK-6716068 : Unable to type into TextArea of modal dialog without clicking the parent window
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,6u10
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_vista
  • CPU: generic,x86
  • Submitted: 2008-06-18
  • Updated: 2019-12-17
  • Resolved: 2019-12-17
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_10-beta"
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25)
Java HotSpot(TM) Client VM (build 11.0-b12, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 6.0.6000

EXTRA RELEVANT SYSTEM CONFIGURATION :
The applet is run on Internet Explorer 7.0.6000

A DESCRIPTION OF THE PROBLEM :
User is unable to type into the textarea in a popup dialog.  The only way to work around is  to click on the parent of the dialog and then click the textarea again.

I have replaced the TextArea object with a TextField object and that works.  It seems it only happens to TextArea.

This is working on 1.5.0_14 with Vista and 1.6.0_05 with XP.  No test on 1.6.0_05 with Vista

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
In the test case sample,

1. click the start button
2. click inside the TextArea and then type.  No text shows up.
Now...
3. Click the parent window( the browser window)
4. Click the TextArea again and then you can type

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
User can click on the TextArea and then start typing
ACTUAL -
User is unable to type into the textarea

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.applet.*;
import java.awt.*;
import java.awt.event.*;

public class MyTest extends Applet implements ActionListener
{
    Button btn;
    Dialog d;
    
    public MyTest() {
    }
    
    
    public void start() {
        btn = new Button("start");
        this.add(btn);
        btn.addActionListener(this);
    }
    
    
    public void actionPerformed(ActionEvent e) {
           if (e.getActionCommand().equals("start"))
           {
               Component c = (Component)this;
               while ( c.getParent() != null )
                  c = c.getParent();
 
               if (!( c instanceof Frame))
                  c = null;
               
              d = new MyTextAreaDlg((Frame)c, "hello", true);
              d.setSize(600, 350);
              d.setVisible(true);
              d.dispose();
           }
    }
    
    
    public class MyTextAreaDlg extends Dialog implements ActionListener
    {
       Button okbtn, cancelbtn;
       TextArea txtarea;
        
       public MyTextAreaDlg(Frame owner, String title, boolean ismodal) {
          super (owner, title, ismodal);
          init();
      }
       
       
       void init() {
          // create the dialog layout and buttons
          setLayout(new BorderLayout());
          Panel p = new Panel();
          txtarea = new TextArea(10, 30);
          //txtarea = new TextField();
          p.add(txtarea);
           
          cancelbtn = new Button("Cancel");
          add("Center", p);
          cancelbtn.addActionListener(this);
          add("South", cancelbtn);
       }
       
        public void actionPerformed(ActionEvent e) {
           if (e.getActionCommand().equals("Cancel"))
              setVisible(false);
        }
    }
    
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Click on the parent of the dialog and then click the textarea again.

Release Regression From : 6u5
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION In the JDK6U23 codebase there is one place where we need to convert Windows time to UTC time. But in the JDK7 codebase all the problematic code has gone through a major refactoring which is a part of the fix for 6806217 implement synthetic focus model for MS Windows So, the CR doesn't require any changes for JDK7 and I've updated the target release for the bug.
08-11-2010

SUGGESTED FIX Valid changes for JDK6U23 workspace are $ hg diff awt_Component.cpp diff -r 865d7090c722 src/windows/native/sun/windows/awt_Component.cpp --- a/src/windows/native/sun/windows/awt_Component.cpp Sat Sep 18 02:38:26 2010 +0400 +++ b/src/windows/native/sun/windows/awt_Component.cpp Mon Nov 08 12:12:39 2010 +0300 @@ -5306,13 +5306,13 @@ void AwtComponent::SendFocusEvent(jint i env->DeleteLocalRef(sequencedEvent); } -void AwtComponent::HeavyweightButtonDown(jlong time) { +void AwtComponent::HeavyweightButtonDown(DWORD time) { JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); jobject target = GetTarget(env); // It should add heavyweight request. env->CallStaticVoidMethod(AwtKeyboardFocusManager::keyboardFocusManagerCls, AwtKeyboardFocusManager::heavyweightButtonDownMID, - target, time & 0xFFFFFFFF); + TimeHelper::windowsToUTC(time)); env->DeleteLocalRef(target); } $ hg diff awt_Button.cpp diff -r 865d7090c722 src/windows/native/sun/windows/awt_Button.cpp --- a/src/windows/native/sun/windows/awt_Button.cpp Sat Sep 18 02:38:26 2010 +0400 +++ b/src/windows/native/sun/windows/awt_Button.cpp Mon Nov 08 12:18:46 2010 +0300 @@ -280,7 +280,7 @@ MsgRouting AwtButton::HandleEvent(MSG *m if (AwtComponent::sm_focusOwner != GetHWnd() && (msg->message == WM_LBUTTONDOWN || msg->message == WM_LBUTTONDBLCLK)) { - HeavyweightButtonDown((jlong)msg->time); + HeavyweightButtonDown(msg->time); } return AwtComponent::HandleEvent(msg, synthetic); } Note that the last change should also be done in some other child classes.
08-11-2010

EVALUATION I just tested the issue using 6u5 on Vista|IE7 and the problem exists there. So, the issue is not a regression introduced in 6u10 (at least, on Vista). Also the problem is reproducible in jdk6 as well. This means that it's a regression of one of the fixes for the focus bugs which have been fixed in jdk6. So far, the problem is reproducible in jdk7 and it's not reproducible in 6u10 b32. It's worth inverstigating further to understand why the test works fine in latest 6u10.
25-09-2008

EVALUATION In AWT Windows code there are a number of the HeavyweightButtonDown calls, it takes 'time' parameter. We should convert Windows time into UTC time before passing it into the heavyweightButtonDown Java method. Interesting that the problem doesn't occur in jdk6u10 b27.
10-07-2008

EVALUATION This is a focus issue that exists only in jdk6u10. AWT prevents the key events from being dispatched, these events are delayed by the typeahead's routines. This happens because one of the markers corresponds to the textarea and the timestamp of the marker is incorrect for some reason.
09-07-2008