Bug ID: JDK-6430553 MouseClick event should not be fired if MouseRelease happened without MousePress

Versions (Unresolved/Resolved/Fixed)

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
7 b27Fixed

J2SE Version (please include all output from java -version flag):
  java version "1.6.0-beta2"
  Java(TM) SE Runtime Environment (build 1.6.0-beta2-b82)
  Java HotSpot(TM) Client VM (build 1.6.0-beta2-b82, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
  Yes

Operating System Configuration Information (be specific):
  Windows XP Professional SP2

Hardware Configuration Information (be specific):
 Intel Pentium III, 730 Mhz, 384 Mb RAM

Bug Description:
 A JPanel contains a window listener that uses the Robot
 to fire a mouse release event when the window is deactivated.
 The Robot fires a mouse release event and a (spurious) mouse
 click event.

Steps to Reproduce (be specific):
 Compile and run the attached program. Place the mouse pointer
 in its window. Then press alt-tab to change the active window.
 The result is:

......
keypress
keyrelease
windowDeactivated
released: 117 159 1
clicked: 117 159 1
J2SE Version (please include all output from java -version flag):
  java version "1.6.0-beta2"
  Java(TM) SE Runtime Environment (build 1.6.0-beta2-b82)
  Java HotSpot(TM) Client VM (build 1.6.0-beta2-b82, mixed mode, sharing)
 
Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
 yes

Operating System Configuration Information (be specific):
 Windows XP Professional SP2

Hardware Configuration Information (be specific):
 Intel Pentium III, 730 Mhz, 384 Mb RAM

Bug Description:
 An empty JFrame is created, and a key listener added to it.
 When asked if it is focusable, it retuns true, when asked if
 it holds the focus it returns false. However, it receives
 key events. It returns false also if it is explicitly told
 to own the focus.

Steps to Reproduce (be specific):

 Compile and run the attached program. When its window appears,
 hit a key (e.g. "a"). This is the output:

W:\borsotti\jtest>java Focus
focus: false true
key typedjava.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyText=Unknown
keyCode: 0x
0,keyChar='a',keyLocation=KEY_LOCATION_UNKNOWN]

EVALUATION By keeping a state mask if a previous PressedEvent had actually happen we may track the situations when CLICK shouldn't occur and block it from posting into the event queue.
26-10-2007
SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/7/6430553
26-10-2007
EVALUATION Will be handled together with 4955581.
22-05-2007
EVALUATION Actually if the pointer stays above the java window after pressing Alt+TAB we have to get MouseReleased event. Othervise, if java window becomes covered by some other window after Alt+TAB MouseReleased shouldn't come. This is what we now observe. The problem is in extra MouseClicked event.
22-05-2007
EVALUATION awt_Component does nothing to track if RELEASE followed by PRESS while sending CLICKED event. But simple and obvious fix may have a hidden fault in the case of two windows. For now we have no standarts for that case. So if we about to fix it then should also note 4955581.
26-05-2006

Relates :	JDK-6746212 - Broken MouseEvents for TrayIcon
Relates :	JDK-6806830 - Bogus MouseDragged events when using a FileDialog
Relates :	JDK-4955581 - [Win] Caret is positioned incorrectly while using Chinese QuanPin Input Method