JDK-6488786 : Vista: Modality is broken on vista 5840 for all native Dialogs.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2006-11-01
  • Updated: 2011-03-07
  • 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 6 JDK 7
6u1Fixed 7 b04Fixed
Related Reports
Relates :  
Description
Modality is completely broken for all native Dialogs on vista 5840. but works fine on vista 5734. Actually parent should be blocked by the child dialog (parent should be inactive), but here child goes behind the parent & allows the user to interact with some components on the parent such as scrolling a text area, selecting an item from the list and clicking on the menuitems (when dialog is active). Even windowEvents are also triggered.

This behavior is seen with the following dialogs - 
1. FileDialog
2. Native PrintDialog
3. Native PageDialog

Step to reproduce:
------------------
1) Run the attached programe.
2) Type some characters into the textarea, so that you can see both the scrollbars.
3) Select "Open FileDialog" button, you can see a file dialog is open. Click on the parent(Frame) . Observe that filedialog goes behind parent.  
4) click on the textarea scrollbar so that you can see the charactes on the textarea scrolling.
5) Click on the "File" Menu. you can see some of the MenuItems & allow us to select some of the menuitem.
6) Click on "Open Dialog", you can see a dialog, 
7) Click on the parent, Observe that parent (frame) is inactive.

I tested this on Mustang b103. This behavior is not reproducible with WinXP with the latest mustang build. Also not reproducible with dialogs created through 'java.awt.Dialog' constructors. This behavior is seen with APPLICATION as well as TOOLKIT MODALITY.

Comments
EVALUATION As I know, on Win95 all the window handles were negative too, if casted to integer/long, so this bug is not Vista-specific.
01-11-2006

SUGGESTED FIX --- WFileDialogPeer.java 2006-11-01 20:59:03.000000000 +0300 *************** *** 85,91 **** // called from native code when the dialog is shown on the screen void setHWnd(long hwnd) { this.hwnd = hwnd; ! if (hwnd > 0) { for (WWindowPeer window : blockedWindows) { window.modalDisableByHWnd(hwnd); if (window.target instanceof EmbeddedFrame) { --- 85,91 ---- // called from native code when the dialog is shown on the screen void setHWnd(long hwnd) { this.hwnd = hwnd; ! if (hwnd != 0) { for (WWindowPeer window : blockedWindows) { window.modalDisableByHWnd(hwnd); if (window.target instanceof EmbeddedFrame) { --- WPrintDialogPeer.java 2006-11-01 20:59:43.000000000 +0300 *************** *** 53,59 **** synchronized void setHWnd(long hwnd) { this.hwnd = hwnd; ! if (hwnd > 0) { for (WWindowPeer window : blockedWindows) { window.modalDisableByHWnd(hwnd); if (window.target instanceof EmbeddedFrame) { --- 53,59 ---- synchronized void setHWnd(long hwnd) { this.hwnd = hwnd; ! if (hwnd != 0) { for (WWindowPeer window : blockedWindows) { window.modalDisableByHWnd(hwnd); if (window.target instanceof EmbeddedFrame) {
01-11-2006

EVALUATION The bug is not reproducible with 5840 build on our Vista Enterprise desktop. However, the problem originally appeared on Vista Ultimate, so I have tried it too and caught the bug. After some investigation I have found that the following line in WFileDialogPeer is wrong (marked with *): void setHWnd(long hwnd) { this.hwnd = hwnd; * if (hwnd > 0) { for (WWindowPeer window : blockedWindows) { window.modalDisableByHWnd(hwnd); On the Vista Ultimate all the window handles (HWNDs) are negative, so the condition 'hwnd > 0' is always wrong and no Java windows that should be blocked are really blocked. I'm not sure if negative values for HWND are valid, but anyway this check should be corrected to 'hwnd != 0'.
01-11-2006