JDK-5028014 : REGRESSION: CTE_REGTEST/Generic/4683300/Test4683300.java fails
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0,5.0u2
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux,linux_suse_sles_8.2
  • CPU: x86
  • Submitted: 2004-04-07
  • Updated: 2006-07-19
  • Resolved: 2006-07-19
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
7Resolved
Related Reports
Relates :  
JDK-4912806 - 1.5.0 Regression: Showing JPopupMenu prevents double clicking on JButton
Relates :  
JDK-6346690 - Mnemonics don't consume proper events
Relates :  
JDK-4847161 - REGRESSION: RegTest-cte CTE_REGTEST/Generic/4683300/Test4683300.java failed
Relates :  
JDK-4942457 - XToolkit: calling toFront() on Frame generates unexpected COMPONENT_RESIZED even
Relates :  
JDK-6396785 - REGRESSION: A component can get unexpected keyTyped event.
Relates :  
JDK-5053242 - In "Reinstall Removed JNLP Application" the default focus is not in table.
Description
Name: aaR10208			Date: 04/07/2004


Filed By       : J2SE-SQA [###@###.###
JDK            : JDK1.5.0-b45 (passed with jdk1.4.2-fcs)
Testbase       : Regression-cte
Platform[s]    : SuSE SLES 8, QuickSilver, RH Linux 9.0 (Gnome)
switch/Mode    : generic
Falling test[s]: CTE_REGTEST/Generic/4683300/Test4683300.java

The bug was originally filed as #4847161 and then closed as dupof#4912806. However, the bug#4912806 is
currently in the 'INTegrated in tiger-25,tiger-beta' state, and the regression test still fails.
According to the comments to #4912806 the regression test may require fix of AWT bug #4942457 which
is also integrated in b30.


Test source location:
=====================
/net/jdk/export/jpse04/Regression/1.5.0/test/CTE_REGTEST/Generic/4683300/Test4683300.java

jtr file location:
==================
/net/jtgb4u4c.sfbay/export/sail15/results.2/tiger/b45/regtest/linux/SuSE_SLES_8_linux-4/workDir/cte/CTE_REGTEST/Generic/4683300/Test4683300.jtr

How to reproduce:
=================
Run the following script (you may need to change its variables)

--- script start ---
#!/bin/sh
RESULT_DIR=`pwd`
WORK_DIR=$RESULT_DIR/workDir/test
REPORT_DIR=$RESULT_DIR/reportDir

#Paths in Java Software:
JT_HOME="/java/re/jct-tools/3.1.2/archive/fcs/binaries"
JEMMY_JAR="/net/jdk.sfbay/export/jpse04/Jemmy/jemmy.jar"
JAVA_HOME="/java/re/jdk/1.5.0/promoted/all/b45/binaries/linux-i586"
TEST_BASE_PATH="/net/jdk/export/jpse04/Regression/1.5.0/test"

#Alternative paths outside Java Software
#JT_HOME="/net/koori.sfbay/onestop/jct-tools/3.1.2/archive/fcs/binaries"
#JEMMY_JAR="/net/jdk.sfbay/export/jpse04/Jemmy/jemmy.jar"
#JAVA_HOME="/net/koori.sfbay/onestop/jdk/1.5.0/promoted/all/b45/binaries/linux-i586"
#TEST_BASE_PATH="/net/jdk/export/jpse04/Regression/1.5.0/test"

#Alternative paths for the NSK site:
#JT_HOME="/net/linux-15/export/home/java/jct"
#JEMMY_JAR="$JT_HOME/jemmy/jemmy.jar"
#JAVA_HOME="/net/linux-15/export/home/java/jdk1.5.0/linux"
#TEST_BASE_PATH="/net/linux-15/export/home/java/regtest.tiger/cte"


TESTVMOPTS="-client"
CLASSPATH="$JT_HOME/classes:$JT_HOME/lib/javatest.jar:$JT_HOME/lib/jtreg.jar"

TEST="CTE_REGTEST/Generic/4683300/Test4683300.java"

mkdir -p $WORK_DIR/scratch 2>&1
mkdir -p $WORK_DIR/jtData 2>&1
mkdir -p $REPORT_DIR 2>&1

#rm $WORK_DIR/jtData/ResultCache.jtw 2>&1

cd $WORK_DIR/scratch

$JAVA_HOME/bin/java -showversion -server -cp $CLASSPATH -DenvVars=TESTJAVAHOME=$JAVA_HOME,TESTVMOPTS=$TESTVMOPTS,DISPLAY=$DISPLAY,HOME=$HOME/.regtest,PATH=/bin:/usr/bin,CPAPPEND=$JEMMY_JAR,TZ=,LC_ALL=en_US,LC_CTYPE=en_US,LANG=en_US,LPDEST= -DDISPLAY=$DISPLAY -DlocalHost=`uname -n` -Dprogram=jtreg com.sun.javatest.regtest.Main -a -v default -batch -params -w "$WORK_DIR" -r "$REPORT_DIR" -t "$TEST_BASE_PATH" "$TEST_BASE_PATH/$TEST"

--- script end ---

Script output:
==============

Test output (jtr part):
=======================
[...]
javax.swing.JPopupMenu[,0,0,153x81,layout=javax.swing.plaf.basic.DefaultMenuLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$PopupMenuBorder@864e43,flags=264,maximumSize=,minimumSize=,preferredSize=,desiredLocationX=600,desiredLocationY=224,label=,lightWeightPopupEnabled=true,margin=,paintBorder=true]
Test Failed
----------System.err:(15/786)----------
Error:
"Wait Any javax.swing.JPopupMenu loaded" action has not been produced in 60019 milliseconds
java.lang.RuntimeException: Test Failed
	at Test4683300.main(Test4683300.java:99)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:495)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:82)
	at java.lang.Thread.run(Thread.java:570)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Test Failed
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Test Failed
result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Test Failed


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Test Failed


Specific machine info:
======================
Hostname: linux-4
OS: SuSE SLES 8
Hostname: sqe12
OS: SuSE SLES 8 (AMD64)



======================================================================
Comments
EVALUATION The problem actually concerns the question of synchronous focus transfer. We're going to investigate it in the context of RFE 6448060 "make requesting focus synchronous". As this bug is no longer reproducible I'm closing it.
19-07-2006
EVALUATION The fix has been again rolled back in mustang-b93 (in the context of the fix to CR 6396785). However because of Swing uses AWT "grab" internal API the test in question along with the regression test provided don't fail. This means the problem is not seen at present.
18-07-2006
SUGGESTED FIX ------- KeyboardFocusManager.java ------- *** /tmp/sccs.eaaqD4 Fri Sep 23 18:09:48 2005 --- KeyboardFocusManager.java Fri Sep 23 17:50:00 2005 *************** *** 2304,2321 **** if (currentFocusOwner != null) { FocusEvent currentFocusOwnerEvent = new CausedFocusEvent(currentFocusOwner, FocusEvent.FOCUS_LOST, temporary, descendant, cause); ! SunToolkit.postEvent(currentFocusOwner.appContext, ! currentFocusOwnerEvent); } FocusEvent newFocusOwnerEvent = new CausedFocusEvent(descendant, FocusEvent.FOCUS_GAINED, temporary, currentFocusOwner, cause); ! SunToolkit.postEvent(descendant.appContext, ! newFocusOwnerEvent); if (focusLog.isLoggable(Level.FINEST)) focusLog.log(Level.FINEST, "2. SNFH_HANDLED for {0}", descendant); return SNFH_SUCCESS_HANDLED; } else if (hwFocusRequest != null && --- 2304,2319 ---- if (currentFocusOwner != null) { FocusEvent currentFocusOwnerEvent = new CausedFocusEvent(currentFocusOwner, FocusEvent.FOCUS_LOST, temporary, descendant, cause); ! SunToolkit.postPriorEvent(currentFocusOwnerEvent); } FocusEvent newFocusOwnerEvent = new CausedFocusEvent(descendant, FocusEvent.FOCUS_GAINED, temporary, currentFocusOwner, cause); ! SunToolkit.postPriorEvent(newFocusOwnerEvent); if (focusLog.isLoggable(Level.FINEST)) focusLog.log(Level.FINEST, "2. SNFH_HANDLED for {0}", descendant); return SNFH_SUCCESS_HANDLED; } else if (hwFocusRequest != null && ------- SunToolkit.java ------- *** /tmp/sccs.RkaqL4 Fri Sep 23 18:09:48 2005 --- SunToolkit.java Fri Sep 23 17:52:07 2005 *************** *** 54,63 **** --- 54,64 ---- private static Field syncLWRequestsField; private static Method wakeupMethod; private static Field componentKeyField; private static Field menuComponentKeyField; private static Field trayIconKeyField; + private static Field isPostedField; /* The key to put()/get() the PostEventQueue into/from the AppContext. */ private static final String POST_EVENT_QUEUE_KEY = "PostEventQueue"; public SunToolkit() { *************** *** 578,587 **** --- 579,610 ---- if(postEventQueue != null) { postEventQueue.postEvent(event); } } + /* + * Post AWTEvent of high priority. + */ + public static void postPriorEvent(final AWTEvent e) { + if (isPostedField == null) { + isPostedField = getField(AWTEvent.class, "isPosted"); + } + PeerEvent pe = new PeerEvent(Toolkit.getDefaultToolkit(), new Runnable() { + public void run() { + try { + isPostedField.setBoolean(e, true); + } catch (IllegalArgumentException e) { + assert(false); + } catch (IllegalAccessException e) { + assert(false); + } + ((Component)e.getSource()).dispatchEvent(e); + } + }, PeerEvent.ULTIMATE_PRIORITY_EVENT); + postEvent(targetToAppContext(e.getSource()), pe); + } + /* * Flush any pending events which haven't been posted to the AWT * EventQueue yet. */ public static void flushPendingEvents() {
30-09-2005
EVALUATION The problem discovered (see above) is XAWT only. This is not regression in XAWT since it was there from the very begining.
30-09-2005
EVALUATION The problem last described is as follows. When the second frame is clicked, while the popup is shown in the first frame, focus is indeed requested for a popup parent component. The first af all this click is processed on the native level that results in generating Java window focus events (WINDOW_LOST_FOCUS for the first frame & WINDOW_GAINED_FOCUS for the second one). The native focused window value is retained untill these focus events are dispatched by DKFM. But while the events posted are going through the event queue the focus request is getting processed and KeyboardFocusManager.shouldNativelyFocusHeavyweight() method is called to check if the request is allowed. Since the native focused window value is yet not changed the request is given a "go" and appropriate focus events are generated for the popup parent component in the first frame and for the opposite component. These focus events are queued after the focus window events generated as a responce to the mouse click. When those focus window events are dispatched the value matching current native focused window is changed accordinly. But then the FOCUS_GAINED event for the popup parent comes and is also processed as if all is Ok. In fact it no longer matches the native focused window. So as the result we have Java focus on one window and native focus on another. To fix this we should make focus events, generated for a focus request in a window, be dispatched first. Thus they would be processed before possible focused window changing.
19-09-2005
EVALUATION Name: azR10139 Date: 04/12/2004 Can not reproduce. Tried to run this test on following platforms: Windows2000 Windows Xp Solaris8(SPARC, i586)/CDE Solaris8(SPARC, i586)/Gnome RedHat9(i586)/Gnome2(default settings) JDK tried: 1.5.0-beta2-b46 1.5.0-beta2-b45 1.5.0-beta2-b44 To eliminate possibility of "floating bug" tried to run test 25 times in a row. 25 times test reported as passed. Full log: java full version "1.5.0-beta2-b45" Note: DummyOrderPanelGUI.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Trace: Start to wait action "Wait Any javax.swing.JPopupMenu loaded" Trace: "Wait Any javax.swing.JPopupMenu loaded" action has been produced in 18 milliseconds with result : javax.swing.JPopupMenu[,0,0,153x81,layout=javax.swing.plaf.basic.DefaultMenuLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$PopupMenuBorder@9bad5a,flags=264,maximumSize=,minimumSize=,preferredSize=,desiredLocationX=600,desiredLocationY=200,label=,lightWeightPopupEnabled=true,margin=,paintBorder=true] Trace: Start to wait action "Wait Any javax.swing.JPopupMenu loaded" Trace: "Wait Any javax.swing.JPopupMenu loaded" action has been produced in 35 milliseconds with result : javax.swing.JPopupMenu[,0,0,153x81,layout=javax.swing.plaf.basic.DefaultMenuLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$PopupMenuBorder@9bad5a,flags=264,maximumSize=,minimumSize=,preferredSize=,desiredLocationX=200,desiredLocationY=200,label=,lightWeightPopupEnabled=true,margin=,paintBorder=true] Trace: Start to wait action "Wait Any javax.swing.JPopupMenu loaded" Trace: "Wait Any javax.swing.JPopupMenu loaded" action has been produced in 20 milliseconds with result : javax.swing.JPopupMenu[,0,0,153x81,layout=javax.swing.plaf.basic.DefaultMenuLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$PopupMenuBorder@9bad5a,flags=264,maximumSize=,minimumSize=,preferredSize=,desiredLocationX=600,desiredLocationY=200,label=,lightWeightPopupEnabled=true,margin=,paintBorder=true] Trace: Start to wait action "Wait Any javax.swing.JPopupMenu loaded" Trace: "Wait Any javax.swing.JPopupMenu loaded" action has been produced in 66 milliseconds with result : javax.swing.JPopupMenu[,0,0,153x81,layout=javax.swing.plaf.basic.DefaultMenuLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$PopupMenuBorder@9bad5a,flags=264,maximumSize=,minimumSize=,preferredSize=,desiredLocationX=200,desiredLocationY=200,label=,lightWeightPopupEnabled=true,margin=,paintBorder=true] Test Passed Possible reason is the thread race in jemmy testing suite. But i can't verify it because this thread race can be very H/W dependant. As for the bug - it is not reproducible. Being checked both manually and automatically i can not find the problem described in bug 4683300. Closing this bug as not reproducible. ###@###.### 2004-04-12 ====================================================================== The bug is easily reproducible in SCA on computer "bublik" RH9+Gnome2+Metacity 2.4.34 with default settings. Name: azR10139 Date: 04/13/2004 I have found machine where i can reproduce this bug. After i inserted some debug code i found that we are closing popup immediately after it is being shown because we are receiving WINDOW_DEACTIVATED event on just-activated window. This can be reproduced only on the fast machine with the XToolkit AWT toolkit. Changing subcathegory to java/classes_awt. ###@###.### 2004-04-13 ====================================================================== Name: ynR10250 Date: 04/15/2004 In fact, there's more serious problem with this test, of which the "two popups" problem is but a part. How to reproduce it: once a test started, frame1 is active and there is a first TextField focused. Right-click on the frame0 to open a popup. Left-click anywhere in the frame1 to close a popup. Now frame1 is active but a first TextField in the frame0 is focused. We have found that after left-click in the frame1 somebody, perhaps some Swing handler, as a first thing tried to focus TextField in frame0 which was the owner of the popup. This unusual request in process, a legitimate requestFocus on frame1 is rejected. We should perhaps find a way to reject the first request; maybe not to do it; or not to reject second request; more research is necessary anyway. ###@###.### suggested we need to record natively focused window as soon as that information became available, in addition to currentFocusedWindow of XKeyboardFocusManagerPeer, and use it in heuristics of shouldNativelyFocusHeavyweight method. Once we have fixed this, we will find a way to eliminate "two popups" bug. ###@###.### -- ======================================================================
28-07-2004