JDK-7092551 : Double-click in TextField sets caret to the beginning
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2011-09-20
  • Updated: 2016-03-08
  • Resolved: 2012-06-12
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.
JDK 7 JDK 8
7u6Fixed 8 b43Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
When double-clicking with the mouse in a java.awt.TextField the caret is set to the beginning. One would expect the selection of the word lying under the mouse cursor. Works fine with javax.swing.JTextField though.

REGRESSION.  Last worked in version 6u26

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
In the executable test case below, double-click anywhere in the TextField.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Word under the mouse cursor is selected.
ACTUAL -
Caret was set to the beginning.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.EventQueue;
import java.awt.Frame;
import java.awt.TextField;

public class TextFieldTest {
	public static void main(String[] args) {
		EventQueue.invokeLater(new Runnable() {
			@Override
			public void run() {
				final Frame frame = new Frame();
				frame.add(new TextField("Lorem ipsum."));
				frame.pack();
				frame.setVisible(true);
			}
		});
	}
}
---------- END SOURCE ----------

Comments
EVALUATION changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a1d825c477bc
08-06-2012

EVALUATION The solution is to use the RICHEDIT control for TextField instad of the EDIT. So some unification for the AwtTextField and AwtTextArea classes is needed because they both will be based on the RICHEDIT control.
05-04-2012

EVALUATION The previous behaviour was that all mouse events were passed to the Windows EDIT component that handled them. Now we have synthetic focuses and all events should handle manually. The Windows EDIT control does not have find word break function so we do not get a word left and right breaks. The suggested solution is to change the EDIT by RICHEDIT.
27-01-2012

EVALUATION I specified 6u10 above mistakenly.
23-11-2011

EVALUATION The root issues is that the RICHED20.DLL need to be loaded for the AwtTextField which contains the FINDWORDBREAK functionality.
17-11-2011

EVALUATION The AwtTextField class does not treat spaces and dots as text delimeters.
17-11-2011

EVALUATION It is a regression in 6u10.
21-09-2011