United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6488786 Vista: Modality is broken on vista 5840 for all native Dialogs.
JDK-6488786 : Vista: Modality is broken on vista 5840 for all native Dialogs.

Details
Type:
Bug
Submit Date:
2006-11-01
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
client-libs
OS:
windows_vista
Sub-Component:
java.awt
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Relates:

Sub Tasks

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
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) {
                                     
2006-11-01
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'.
                                     
2006-11-01
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.
                                     
2006-11-01



Hardware and Software, Engineered to Work Together