JDK-6386592 : REGRESSION: Frame doesn't get focus back when dialog become closed
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-02-16
  • Updated: 2011-02-16
  • Resolved: 2006-04-05
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 6
6 b79Fixed
Related Reports
Duplicate :  
JDK-6403372 - REGRESSION: Focus problems after cancelling JFileChooser with null parent
Relates :  
JDK-6689088 - Focus traversal doesn't work in the reverse order / related to the SR 70175950 / CR 6684528
Relates :  
JDK-6300062 - JDialog need to support true parent-less mode
Relates :  
JDK-6518198 - Closing modal JDialog does not return focus to JFrame
Relates :  
JDK-6387788 - Browser will lost focus after Applt show a dialog.
Relates :  
JDK-6684528 - keyevents are lost in new window
Description
FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b71)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b71, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows XP [Wersja 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Keyboard shortcut for menu items work only once. For the first time after application has been launched correct menu option is executed, no matter which. But when I press again the same keyboard shortcut, or any other defined shortcut, nothing happens.  But when I swicth to another application (by Windows Alt+Tab), then when I am back the shortcut works again but again only once.

In J2SE 5 everything works properly.

Keyboard shortcut was defined by means of  setAccelerator(),

	menuItem.setMnemonic('a');
	menuItem.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_A,ActionEvent.CTRL_MASK));

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

I have prepared small example program (only 10kb in zip file).  The file 
contains two directories src -- with sources in one package, (this is remnants of a larger application)
install -- with two further subdirectories:
-> deploy -- which contains a jar file and a StartTestMenu6.bat file to execute this jar. Jar mainifest do not specify main class, so the bat file is neccessary, this jar was created with Java 5 update 6
-> scripts -- simple bat to create jar file.

To observe incorrect behavior simply run the StartTestMenu6.bat (change 
path to java.exe before you do this) , then after the main window appears 
press for example Ctrl+M. That results in  a message box, close it and 
press Ctrl+M again. Now nothing happens.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Attached seperatly
---------- END SOURCE ----------

Release Regression From : 5.0u6
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
Comments
SUGGESTED FIX See the webrev here: http://javaweb.sfbay/jcg/1.6.0-mustang/awt/6386592
21-03-2006
EVALUATION Actually the problem 4810575 consisted in that an owned window didn't activate its owner when it gets disposed. But this concerns only a Window (not Frame/Dialog) because its decorated owner (Frame/Dialog) holds native activation and Windows doesn't consider it requiring it. So, we should activate an owner only in case of an owned simple window.
17-03-2006
EVALUATION As it appeared the bug is actually a regression of the fix to this CR: 4810575 "Frame does not receives focus after closing of the owned window", integrated in b53. The problem is that a dialog after closing synthesizes native activation message on its parent. In case of the testcase attached this is an invisible frame, a parent of JOptionPane. I simplified the test to pure AWT. See attached AWTTest.java.
15-03-2006
EVALUATION This is a regression of 6300062 in JDK6.0b59. That fix was in direct usage of parentless dialogs in JOptionPane. Seems focus machinery (we should decide how awt deals with it) is not ready for these changes and pehaps just trying to requestFocus on null component although Frame visibly the focus owner but I haven't verified it though. Interestigly how does it look on Linux KDE. The problem is not reproducible with XAWT with JDK6.0b71 but MToolkit behaves odd: Pressing CTRL+T opens a dialog. If I close it I'm getting blocked input in that JFrame and event focus change doesn't help. Opening the dialog via the menu only helps.
17-02-2006
EVALUATION On invoking the shortcut the first time, a JDialog is shown that is parented to a hidden shared owner frame. In 1.5.0, when the dialog was dismissed, focus went back to the frame that invoked the dialog. In Mustang, this seems to not be the case. See attached menutestTest.java. Launch it and put focus on the text field in the center. Hit CTRL-T to show a dialog. Dismiss the dialog and focus doesn't go back to the text field. This is a regression. Since the frame isn't getting focus again, the accelerators don't work.
16-02-2006