JDK-6457980 : regtest fails: java/awt/Focus/DisposedWindow/DisposedWindow.java
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,solaris_10
  • CPU: generic,x86,sparc
  • Submitted: 2006-08-08
  • Updated: 2014-02-27
  • Resolved: 2011-03-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.
JDK 7
7 b15Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Description
the test fails on current AWT dolphin's ws, but passes on mustang (b94).

Comments
SUGGESTED FIX The webrev: http://sa.sfbay.sun.com/projects/awt_data/7/6457980
19-06-2007

EVALUATION I made the test manual. And noticed the following. If at the time the owned window has focus I'm clicking on its component and then disposing the window, the Frame receives focus on its button. If I'm not clicking in the window (so that it would be only activated programmatically on its showing) and then disposing it, the Frame's button doesn't get focus. What I've found is that in the first case, after the disposal of the window, the Frame receives WM_TAKE_FOCUS but it doesn't in the second case. However, in the both cases the native focus is always in the frame, on the focus proxy component. It doesn't leave it! So, I wonder why the WM sends it WM_TAKE_FOCUS. However, if we have a frame with some hw components inside and we're switching focus b/w the components by clicking, the WM also sends the frame WM_TAKE_FOCUS. I suppose that we should treat this as a hint to change focus in the frame. (But actually we don't need this WM_TAKE_FOCUS as we change the inside focus by click.) A simle Window has InputHint False and WM_TAKE_FOCUS False. I believe that in this case WM shouldn't be affected at all when clicking in the window. But as the practice shows this is not the case. It's rather a good turn but I thought that was our responsibility, no WM's...
13-06-2007

EVALUATION What I'm seeing now is the following. A frame is show, then an owned window is shown. The latter gains focus. Then it gets disposed. After that no Java focus events is generated. However the frame looks natively active (and it receives key events). The button in the frame is not focused and when I'm pressing it I'm observing the folowing focus events: - FOCUS_LOST on the button in the window - WINDOW_LOST_FOCUS on the window - WINDOW_GAINED_FOCUS on the frame - FOCUS_GAINED on the button in the frame Thus, on the window disposal we dont't generate proper focus events.
09-06-2007

EVALUATION The test has been created for a Windows issue. It passed on UNIX because of our wrong behavior: the newly opened window (java.awt.Window) didn't gain focus by default. This has been fixed in JDK 7 b02 (see 6426132). Since that the test started to fail.
09-06-2007