United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6181725 : Non-focusable frame becomes active when maximized, on win32

Details
Type:
Bug
Submit Date:
2004-10-20
Status:
Closed
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2005-02-12
Component:
client-libs
OS:
windows_xp
Sub-Component:
java.awt
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2
Fixed Versions:

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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
                                     
2005-01-14
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
                                     
2004-10-20



Hardware and Software, Engineered to Work Together