JDK-6181725 : Non-focusable frame becomes active when maximized, on win32
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-10-20
  • Updated: 2011-01-19
  • Resolved: 2005-02-12
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 b24Fixed
Related Reports
Relates :  
JDK-6182359 - Non focusable frame prevents any of it's child windows from gaining focus, on XToolkit
Relates :  
JDK-6399303 - Non-Focusble window steals focus from other applications.
Relates :  
JDK-6224544 - PIT: Non-focusable frame becomes active when it is iconified and restored, win32
Relates :  
JDK-6253913 - Reg. TextField in a Window having an iconified frame as parent behaves improperly
Description
An active window is either the frame or dialog that has the focus owner or the first frame / dialog that owns the focused window. So deriving from this, a non-focusable frame can not become an active window. This is honored when a non-focusable frame is first shown on the screen. But when I maximize the frame and restore it, it automatically becomes active which is incorrect. Because it is still non-focusable. DKFM.getActiveWindow() returns the frame instance after it is maximized.

This is reproducible on 1.4.2, tiger and mustang on WinXP. Not reprodcuible on solaris/linux with XToolkit as well as Motif. On Solaris, the frame is always non-active. 

I have attached a sample test. Execute the sample test. You would see a frame with a grayed out title bar. Check the console. A null would have been printed (refers to active window). Now maximize the frame. Click on the button. If the frame instance is printed on the console and title bar becomes blue, the bug is reproduced.
###@###.### 10/20/04 07:21 GMT

This is reproducible by clicking a choice on a non-focusable frame. As soon as the choice's drop-down is shown and hidden, the non-focusable frame becomes active.
Comments
SUGGESTED FIX Here's a list of files modified: src/share/classes/java/awt/Window.java src/share/classes/sun/awt/EmbeddedFrame.java src/share/classes/java/awt/peer/WindowPeer.java src/solaris/classes/sun/awt/X11/XWindowPeer.java src/solaris/classes/sun/awt/motif/MWindowPeer.java src/solaris/native/sun/awt/awt_TopLevel.c src/solaris/native/sun/awt/awt_p.h src/solaris/native/sun/awt/awt_TopLevel.h src/solaris/native/sun/awt/awt_MToolkit.c src/solaris/native/sun/awt/awt_MToolkit.h src/windows/classes/sun/awt/windows/WWindowPeer.java src/windows/classes/sun/awt/windows/WDialogPeer.java src/windows/native/sun/windows/awt_Window.cpp src/windows/native/sun/windows/awt_Window.h src/windows/native/sun/windows/awt_Frame.cpp src/windows/native/sun/windows/awt_Dialog.cpp make/sun/awt/mapfile-mawt-vers The fix itself is attached. ###@###.### 2005-1-14 14:08:14 GMT
14-01-2005
EVALUATION Could not reproduce on Win2000 and WinXP with tiger. Seems that the test attached is not for this bug because when I run the test I haven't saw anything in console. Maximizing Frame do not change the color of title bar too. ###@###.### 10/20/04 11:46 GMT I have run the test and was able to reproduce the bug, but in another way. First, I couldn't maximize the frame because maximize button was disabled, and double-click on title bar did nothing. Second, when I minimize the frame and restore it again, it becomes active and pressing the button shows frame instance in the console. After looking into AWT native code I've founded some lines related to the bug. In AwtWindow::ToFront() additional flag SWP_NOACTIVATE should be used while calling ::SetWindowPos for non-focusable frames. In AwtFrame::SetState() we use different modes SW_SHOWMAXIMIZED and SW_MAXIMIZE in ::ShowWindow() when maximizing the frame, but that constants are really equals according to winuser.h (SW_SHOWMAXIMIZED == SW_MAXIMIZE). That were programmatic window state changes. As for user actions (for example, minimizing by using the button in taskbar), Windows automatically activate the window, so we must filter such attempts for non-focusable windows and don't pass the activation into Java. The best way to implement such filtering is using CBT hook procedure. ###@###.### 10/25/04 11:22 GMT It's good to have such a hook. It will solve the problem of non-focusable windows completely. I'm going to combine this fix with the fix for 6182359 that will correctly track non-focusable windows. ###@###.### 2004-12-03 13:43:41 GMT
20-10-2004