JDK-4504319 : Focus in Jtextfield gets messed up when covered by a window (dtterm)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1_01
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-09-18
  • Updated: 2002-01-15
  • Resolved: 2002-01-10
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
1.3.1_03Resolved
Related Reports
Duplicate :  
Description
When a java application has 2 or more Jtextfields, focus in the Jtextfields 
gets messed up when a UNIX dtterm covers it partially and closed back. This 
only happens if the Open key on the left edge of the keyboard is used to 
close the dtterm. Everything works fine when the mouse is used. The following 
test case shows the problem. 
The problem occurs in jdk 1.3.1_01 on solaris 8. It works fine in 1.4 beta. But the customer needs a fix for 1.3.1_01.


When the program first comes up, three JTextFields are displayed.
You can click in any of them and type and everything works fine.
Now, cover a portion of the java application with a UNIX dtterm
and then close the dtterm.  Now when you click in each JTextField,
and try to type they will not all work.  If you click in a JTextField
which does not have the blinking insert caret, and then open the UNIX
dtterm window so that it covers the java program, and then close
the dtterm again, you will get an extra blinking caret. Repeating
this, you can get blinking carets in all three JTextFields.  At least
one of the JTextFIelds will not accept keyboard entry.

NOTE:
=====
If I only ever use the mouse to open and close the dtterm, the java 
application works correctly.  If I use the Open key on the left edge 
of the keyboard to close the dtterm, then the focus starts to get confused.




// FocusBug.java code

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class FocusBug extends JFrame {
	JTextField text1;
	JTextField text2;
	JTextField text3;

	FocusBug() {
	    Container content = getContentPane();
	    content.setLayout(new GridLayout(3, 1));
	    setSize(new Dimension(800, 200));
	    text1 = new JTextField("textfield 1 ");
	    text2 = new JTextField("textfield 2 ");
	    text3 = new JTextField("textfield 3 ");
	    content.add(text1);
	    content.add(text2);
	    content.add(text3);
            setLocation(200, 200);
	    addWindowListener (new WindowAdapter() {
		public void windowClosing(WindowEvent e) {
		    System.exit(0);
		}
		public void windowOpened(WindowEvent e) {
			repaint();
			text1.requestFocus();
		}
	    });
	    validate();
	    setVisible(true);
	}

	public static void main(String[] args) {
	    new FocusBug();
	}
}


Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_03 FIXED IN: 1.3.1_03 INTEGRATED IN: 1.3.1_03
14-06-2004

SUGGESTED FIX *** 1100,1110 **** #endif NOMODALFIX } break; case FocusIn: ! if (event->xfocus.mode == NotifyNormal) { #ifndef NOMODALFIX if (!awt_isModal() || awt_isWidgetModal(w)) { #endif NOMODALFIX awt_setActivatedShell(w); JNU_CallMethodByName(env, NULL, this, "handleActivate", "()V"); --- 1100,1110 ---- #endif NOMODALFIX } break; case FocusIn: ! if (event->xfocus.mode == NotifyNormal || event->xfocus.mode == NotifyWhileGrabbed) { #ifndef NOMODALFIX if (!awt_isModal() || awt_isWidgetModal(w)) { #endif NOMODALFIX awt_setActivatedShell(w); JNU_CallMethodByName(env, NULL, this, "handleActivate", "()V"); ###@###.### 2002-01-10
10-01-2002

EVALUATION This was undoubtedly fixed by the focus rearchitecting (4290675). ###@###.### 2001-09-18 Because this problem does not occur in the current release of the JDK, it cannot have a priority higher than 4. If a fix is needed in a release prior to 1.4, it must be handled as a technical escalation through CTE. ###@###.### 2001-09-18
18-09-2001