JDK-6438965 : Regression: Focus change in JInternalFrame.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-06-15
  • Updated: 2010-04-02
  • 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 6
6 b92Fixed
Related Reports
Relates :  
JDK-6448060 - make requesting focus synchronous
Description
Running the attached test case, the startup focus on JDK 1.6 is different
from the startup focus on JDK 1.5, for JInternalFrame.

Run the attached test case on JDK 1.6: 
Click on the JInternalFrame.
The focus is on javax.swing.JPanel.

On JDK 1.5 the focus is on javax.swing.JButton, 
so that is the expected result.

Note that a JInternalFrame created after startup with the 
"New" menu item has the focus on javax.swing.JButton, same as JDK 1.5.
Comments
EVALUATION I wanted to expand on the problem a bit more. Here's the sequence of events when you click on an internal frame: an AWTEventListener in BasicLookAndFeel invokes setSelected on the internal frame setSelected invokes restoreSubcomponentFocus. MouseListener in BasicInternalFrameUI invokes setSelected setSelected again invokes restoreSubcomponentFocus. The first restoreSubcomponentFocus gives focus to the button; this is the correct behavior. When restoreSubcomponentFocus is invoked the second time through, isSelected is true and the code ends up trying to requestFocus on lastFocusOwner (getMostRecentFocusOwner() returns getFocusOwner(), which returns lastFocusOwner). JInternalFrame sets the lastFocusOwner field when a property change event is received from the KeyboardFocusManager. As focus changes are asynchronous, the lastFocusOwner field will not have been updated at the time it's value is used, and requestFocus is invoked on the wrong component. Mike's fix addresses this by setting the lastFocusOwner field immediately when requestFocus is invoked on it. The only problematic case with this change is if requestFocus were to fail. None-the-less this is what the old code did, so that it won't give any worse behavior than we've always had.
11-07-2006
EVALUATION The local variable lastFocusOwner was introduced in the fix for 4302764: focus is not set in JInternalFrame, which was integrated in mustang b34. It is preventing the field lastFocusOwner from getting set. The local variable lastFocusOwner is not needed.
10-07-2006
EVALUATION The fix is to set the field lastFocusOwner and not the local variable lastFocusOwner in restoreSubcomponentFocus() in JInternalFrame.java. The local variable lastFocusOwner is not needed.
27-06-2006
EVALUATION Fix in mustang.
15-06-2006