Bug ID: JDK-6578583 Regression: Modality is broken in windows vista home premium from jdk1.7 b02 onwards.

Versions (Unresolved/Resolved/Fixed)

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	JDK 7	Other
6u12Resolved	7 b25Fixed	OpenJDK6Fixed

I have a frame which contains some buttons, clicking on each button will invoke different kinds of modal dialogs like filedialog , page dialog , print dialog & java dialog.
When any one of the modal dialog is visible, it is suppose to block the parent which include moving the parent , minimize & maximize. but on windows vista home premium os the parent can be minimized & can be maximized which intend triggers WindowEvent in WindowStateChanged(). When the parent is maximized & brought back to normal state the parent is above the modal dialog & we can perform all the operation to the modal dialog even when the parent is above the dialog. for example i can type in the textfield of the dialog, or select folder or navigate in the filedialog . which is incorrect. This works fine in jdk1.6.0 & their update releases. It even works fine in jdk1.7 b01 , but fails from jdk1.7 b02 onwards till b15 pit build. Hence this is a regression.

Step to reproduce:-
------------------
1) Run the attached program.
2) select any button. for example : "Open FileDialog".
3) Click on the parent. the file dialog flickers , which is correct.
4) Click on parent title & drag the frame some where on the screen. If frame is moved then the bug is reproduce.
5) click on the minimize button on the frame. If frame ( parent) gets minimized then the bug is reproduced. Check on the console events are triggered describing the state of the parent.
6) Get the minimized frame to normal state , by clicking on the minimized frame on the taskbar. this will trigger the events.
7) Click on the maximized button of the frame. now the frame gets maximized ,by triggering the window event. Now get the frame to normal state. Observe that parent is on the modal dialog. Now you can select any file or folder & you can able to navigate.

EVALUATION The fix for the bug includes the changes mentioned above. The fix also replaces the WS_EX_NOACTIVATE style with the WS_DISABLED style. Native applications like Notepad use the WM_DISABLED style to disable mouse and keyboard input to the blocked windows. The changes should fix 6572263, 6571808, 6438993.

14-03-2008

EVALUATION These Vista-specific issues are reproducible using Windows Vista Business RTM. - maximizing/minimizing a window The problem is that user is able to maximize/minimize blocked window. Current implementation of AWT modality uses the CBTProc hook procedure to prevent activating blocked window. This procedure should also filter the maximizing/minimizing events. That is, the problem can be easily fixed by processing the HCBT_MINMAX messages in the same way as other messages. - moving a window The problem is that user is able to move blocked window. The MouseProc hook procedure is used to prevent the mouse events. The hook procedure retrieves the blocker window and displayes the blocker window above the blocked windows when any mouse message is coming to any blocked window. Then the procedure passes the message to the CallNextHookEx function and return the value it returns. To fix the problem it's enough just to return nonzero value instead of call the CallNextHookEx function. In other words, the system will not pass the messages to the target window procedure. It's still not clear why current implementation works on Windows XP. I spent a while investigating this and came to nothing.

31-07-2007