JDK-4416097 : JCK1.3a: interactive: Test stop responding to keyboard in JMenuItem.setAccelerat
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    linux,solaris_8,windows_95,windows_nt linux,solaris_8,windows_95,windows_nt
  • CPU: x86,sparc
  • Submitted: 2001-02-16
  • Updated: 2001-08-07
  • Resolved: 2001-04-25
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
Duplicate :  
JDK-4415580 - JCK 1.3a: AWT and swing components does not response to keyboard in plugin/Win32
Duplicate :  
JDK-4411510 - JRE1.4b49 SwingSet2: JTextFields in JTable demo are not editable in Windows.
Relates :  
JDK-4450539 - JCK1.3a: interactive: Test stop responding to keyboard in JMenuItem,b61.
Description

Name: asR10013			Date: 02/15/2001



Bug description ---> The test stop responding to keyboard after selecting menu item via accelerator.
****************************************************************************
Failing Test:
=============
api/javax_swing/interactive/JMenuItemTests.html#JMenuItem

JCK : 
=====
jck1.3a

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


Platforms:
=============
Windows 95

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

jtr file location:
==================
/net/jtgb4u4c.eng/export/sail7/JavaWebServer1.1.3/public_html/QA/merlin/b51/jck13a/win32/win95_client_linux-19/workDir/api-interactive/javax_swing/interactive/JMenuItemTests_JMenuItem.jtr

How to reproduce:
====================
1. Run the following script (You may need to set JDK and TESTBASE).
2. Press Alt+m to bring up popup menu, then Shift+1 to select menu item.
3. Press Alt+m again.
4. Also, press "No" button at the bottom of the test window and try to type anything in the "failure details" text field.

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

Source
======
#!/bin/ksh

SWITCH=$@

JDK=x:/usr/local/java/jdk1.4/win32/
TESTBASE=x:/net/sqesvr/export/st1/JCK-13a/
JCK=${TESTBASE}/JCK-runtime-13a/

executeClass=javasoft.sqe.tests.api.javax.swing.interactive.JMenuItem.JMenuItemTests
excludeCmd="-TestCaseID JMenuItemTest0004"
executeClassArgs="-TestDirURL file:///${JCK}tests/api/javax_swing/interactive/JMenuItemTests.html#JMenuItem"
executeTestURL=""

CLASSPATH=${JCK}/classes\;${JCK}/javatest.jar
DISPLAY=${DISPLAY-$HOST:0.0}
LD_LIBRARY_PATH=${JCK}/lib/${ARCH}
PATH=$JDK/bin\;$PATH

export PATH CLASSPATH DISPLAY LD_LIBRARY_PATH

${JDK}/bin/java ${SWITCH} -showversion -cp ${CLASSPATH} -verify -Xfuture -Djava.security.policy=${JCK}/lib/jck.policy ${executeClass} ${excludeCmd} ${executeClassArgs} ${executeContextArgs} ${executeTestURL}

Test output:
=============
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b51)
Java HotSpot(TM) Client VM (build B51, mixed mode)
		 
Specific Machine Info:
=====================
hostname: linux-19

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


======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2 VERIFIED IN: merlin-beta2
17-09-2004
EVALUATION Unable to reproduce, emailing submitter for more information. scott.violet@eng 2001-02-21 Here is some more information from submitter: The test task is: "Press Alt+m to bring up popup menu then Shift+1/2/3/4 to select menu item". The first time test window is shown the radiobutton "Dalmatian" has focus. First time Altm+m is pressed popup menu is shown and pressing Shift+1/2/3/4 selects corresponding radio-button, but no components has focus rect drawn. Pressing Alt+m second time does not show popup menu. Moreover, at this point test window looks as has no focus at all: clicking on the radiobuttons/buttons does not cause focus rect to be drawn, Tab/Shift+Tab does not focus any component, and it's impossible to type anything in the "Failure reason" text field after pressing "No". Additional info: When test window loose focus (e.g. minimizing test window or switching to another window then back to the test window) focus rect becomes visible again and test behaves correctly untill pressing Alt+m. Pressing Shift+1/2/3/4 (without preceding Alt+m) selects corresponding radiobuttons but does not cause focus to be lost. Pressing Alt+m to bring up popup menu then Esc (without selecting any item) causes focus to be lost. The focus is lost even if menu is opened via mouse click. Still reproducible on Merlin-b52. Windows version is: Windows 95. [Version 4.00.1111] Java version is: java version "1.4.0-beta" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b52) Java HotSpot(TM) Client VM (build B52, mixed mode) As focus returns if you activate another window and then bring java window back to front it looks more like an awt bug. It is also worth noting that I can't reproduct this on NT or Solaris. scott.violet@eng 2001-03-02 Commit to fix in Merlin-beta (JCK failure). eric.hawkes@eng 2001-03-11 Name: osR10079 Date: 04/02/2001 This is regression to my fix for 4380809 (Focus disappears after deiconifying frame). Namely, in this fix i've tried skip some unnecessary Win32 event (WM_ACTIVATE and WM_SETFOCUS) which window receives after deiconifing. And i assumed that in our code we always receive WM_ACTIVATE when we activate window (from java point of view). But in case embedded frame and frame after closing focusable window this is not true, we receive only WM_SETFOCUS. So, to fix this problem we have to use new private member of AwtComponent (something like "shouldSkipNextSetFocus"). I don't like this kind of fix, but, I think, this is the only way to fix 4380809 :( ###@###.### 03 Apr 2001 ====================================================================== Name: osR10079 Date: 04/11/2001 > Another testcase fails due to the bug: > JMenuItemTest0003: Failed. JMenuItem setMnemonic() does not behave as expected. > Verifed in merlin b59. The first mention of JMenuItemTest0003 test appers after integrated bug-fix. But this is not regression because (as tester wrote) this failure reprodused on earlier builds. So, i'm going to moving bug back to intagrated state and suggest to file new bug against failure of JMenuItemTest0003. BTW, this bug was a Win32 only, and JMenuItemTest0003 failure is Linux specific. ###@###.### 11 Apr 2001 ======================================================================
17-09-2004
SUGGESTED FIX Name: osR10079 Date: 04/02/2001 ###@###.### 03 Apr 2001 *** /tmp/dKVayCa Wed Mar 21 16:16:08 2001 *************** *** 636,641 **** // Cache for FindComponent static HWND sm_cursorOn; + BOOL m_skipNextSetFocus; + private: /* * The association list of children's IDs and corresponding components. *** /tmp/dqKaiFa Wed Mar 21 16:22:20 2001 *************** *** 167,172 **** AwtComponent::BuildDynamicKeyMapTable(); kbdinited = TRUE; } + m_skipNextSetFocus = FALSE; } AwtComponent::~AwtComponent() *************** *** 951,981 **** break; case WM_SETFOCUS: ! mr = (!sm_suppressFocusAndActivation && (sm_focusedWindow != NULL)) ? WmSetFocus((HWND)wParam) : mrConsume; break; case WM_KILLFOCUS: - /* - * We should process WM_KILLFOCUS independently from - * sm_focusedWindow. Because when we deactivate window, - * we receive WM_ACTIVATE(WA_INACTIVE) before WM_KILLFOCUS, - * and sm_focusedWindow always will be NULL here in this case. - * Fix for 4402942 by ###@###.### - */ mr = (!sm_suppressFocusAndActivation) ? WmKillFocus((HWND)wParam) : mrConsume; break; case WM_ACTIVATE: if (!sm_suppressFocusAndActivation && ! (!(BOOL)HIWORD(wParam) || (LOWORD(wParam) == WA_INACTIVE))) { ! mr = WmActivate(LOWORD(wParam), (BOOL)HIWORD(wParam), ! (HWND)lParam); AwtToolkit::GetInstance().UpdateThemesStatus(); } else { mr = mrConsume; } ! break; #if defined(WIN32) case WM_CTLCOLORMSGBOX: break; case WM_SETFOCUS: ! mr = (!sm_suppressFocusAndActivation && !m_skipNextSetFocus) ? WmSetFocus((HWND)wParam) : mrConsume; + m_skipNextSetFocus = FALSE; break; case WM_KILLFOCUS: mr = (!sm_suppressFocusAndActivation) ? WmKillFocus((HWND)wParam) : mrConsume; break; case WM_ACTIVATE: + { + UINT nState = LOWORD(wParam); + BOOL fMinimized = (BOOL)HIWORD(wParam); if (!sm_suppressFocusAndActivation && ! (!fMinimized || (nState == WA_INACTIVE))) { ! mr = WmActivate(nState, fMinimized, (HWND)lParam); AwtToolkit::GetInstance().UpdateThemesStatus(); + m_skipNextSetFocus = FALSE; } else { + if (!sm_suppressFocusAndActivation + && fMinimized && (nState != WA_INACTIVE)) + { + m_skipNextSetFocus = TRUE; + } mr = mrConsume; } ! } ! break; #if defined(WIN32) case WM_CTLCOLORMSGBOX: *************** *** 1406,1411 **** } sm_focusOwner = GetHWnd(); + sm_focusedWindow = GetTopLevelParentForWindow(sm_focusOwner); if (sm_realFocusOpposite != NULL) { hWndLostFocus = sm_realFocusOpposite; ======================================================================
17-09-2004