JDK-4450227 : JCK1.3a:interactive:Test stop responding to Shift key in JMenuItem,b61,(4416097)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: x86,sparc
  • Submitted: 2001-04-25
  • Updated: 2001-08-11
  • Resolved: 2001-08-07
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.4.0 beta2Fixed
Related Reports
Relates :  
JDK-6236236 - JCK 14a failure: api/javax_swing/interactive/JMenuItemTests setAccelerator(KeyStroke) Test
Relates :  
JDK-4450539 - JCK1.3a: interactive: Test stop responding to keyboard in JMenuItem,b61.
Description
Bug description :
================
The test stop responding to Shift Key ,when the anyone of the RadioButton or Resume/Pause Button is selected using Mouse.
****************************************************************************

Failing Test:
=============
api/javax_swing/interactive/JMenuItemTests.html#JMenuItem

JCK : 
=====
jck1.3a

Test source location:
====================
file:/net/jdk/export/disk8/local.java/jck1.3a/JCK-runtime-13a/tests/api/javax_swing/interactive/JMenuItemTests.java

JDK, switches Info:
====================
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b61)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b61, mixed mode)

jtr file location:
==================
file:/net/jtg-i108/export/home/jtg-test/JH_JDK14_b60_jck13a_C1Xmixed/workDir/api/javax_swing/interactive/JMenuItemTests_JMenuItem.jtr

How to reproduce:
====================
1. Run the attached script.(interactive_JMenuItemTest0004.ksh)
2. Press Alt+m to bring up popup menu, then Shift+1 to select menu item.
3. Select anyone RadioButton or Resume/Pause Button using Mouse.
4. Press Alt+m again to bring up popup menu, then Shift+1 to select menu item.
5. The Shift Key will not Response.

You will see the ShiftKey does not response to keyboard at all.

Specific Machine Info:
=====================
X86:
====
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b61)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b61, mixed mode)
jtg-i108>info
Hostname: jtg-i108
Hostid: 2e59ad5f
Release: 5.8
Kernel architecture: i86pc
Application architecture: i386
Hardware provider: 
Domain: javasoft.eng.sun.com
Kernel version: SunOS 5.8 Generic February 2000
===========
Status of processor 0 as of: 04/24/01 17:26:37
  Processor has been on-line since 04/04/01 17:31:40.
  The i386 processor operates at 200 MHz,
        and has an i387 compatible floating point processor.
Status of processor 1 as of: 04/24/01 17:26:37
  Processor has been on-line since 04/04/01 17:31:43.
  The i386 processor operates at 200 MHz,
        and has an i387 compatible floating point processor.
===========
                           Solaris 8 s28_38shwp2 INTEL
           Copyright 2000 Sun Microsystems, Inc.  All Rights Reserved.
                            Assembled 21 January 2000
Sparc:
======
Hostname: jtg-s111
Hostid: 808dc389
Release: 5.8
Kernel architecture: sun4u
Application architecture: sparc
Hardware provider: Sun_Microsystems
Domain: javasoft.eng.sun.com
Kernel version: SunOS 5.8 Generic February 2000
===========
Status of processor 0 as of: 04/24/01 18:02:13
  Processor has been on-line since 04/04/01 17:41:54.
  The sparcv9 processor operates at 168 MHz,
        and has a sparcv9 floating point processor.
Status of processor 1 as of: 04/24/01 18:02:13
  Processor has been on-line since 04/04/01 17:41:58.
  The sparcv9 processor operates at 168 MHz,
        and has a sparcv9 floating point processor.
===========
                           Solaris 8 s28_38shwp2 SPARC
           Copyright 2000 Sun Microsystems, Inc.  All Rights Reserved.
                            Assembled 21 January 2000


Additional JCK related info:
============================
URL to find JCK test owners: http://javaweb.eng/jck/usr/owners.jto


======================================================================


sureshchandar.subramaniam@Eng 2001-04-24
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2 VERIFIED IN: merlin-beta2
14-06-2004
EVALUATION Mark, I am reassigning this to you as I'm hoping it will be dealt with along when 4104424 gets fixed. In this test when the popup comes up the second time the radio button retains focus and thus the menu will not hide. scott.violet@eng 2001-05-01 Name: pzR10082 Date: 06/07/2001 The problem is that pressing Shift+1 does not always generate the same keycodes. When there's no focus owner (no radio button is selected), and Shift+1 is pressed, these two events are sent: KEY_PRESSED keyChar=='!' keyCode==49 (VK_1) KEY_RELEASED keyChar=='!' keyCode==49 (VK_1) When a radio button is selected, the KEY_PRESSED event is different: KEY_PRESSED keyChar=='!' keyCode==517 (VK_EXCLAMATION_MARK) KEY_RELEASED keyChar=='!' keyCode==49 (VK_1) Swing gets confused in the latter case, because it sees a key is released that has never been pressed before. It doesn't call processKeyBindings() (see JComponent.processKeyEvent() for details). This happens on Solaris and Linux but not on Windows. This also seems to happen with Shift+something keystrokes only. If the test used Alt or Ctrl instead, it would work fine. I've turned to Russian AWT guys for help, and they've investigated this down a bit. It turned out that events with keycode 49 were sent by AWT itself, while those with keycode 517 came from inside input-method code. ###@###.### 2001-06-07 ====================================================================== Commit to fix in merlin-beta2 (JCK) eric.hawkes@eng 2001-06-18 When I use my build (with the fix for 4478258) I cannot reproduce this bug, but I can reproduce it with build 70. However, button still seems to be drawn as though it has focus. eric.hawkes@eng 2001-07-10
10-07-2001