Bug ID: JDK-6503472 REG: An extra icon is created on the window list (ALT+TAB list) for Native File Dialog, Win32

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
6u12Resolved	7 b15Fixed

I am opening a native FileDialog and when the file dialog is visible, I am pressing ALT+TAB. An extra icon is shown on the window list for the FileDialog. This is incorrect. FileDialog should not be shown on the window list and none of the native applications behave that way. 

This is a regression introduced in Mustang in b40 when modality changes were integrated. Not reproducible on Mustang-b36 and Tiger. This is reproducible only on Win32 platforms. This is reproducible on JDK7-b04 also where the other bug 6488834 is actually fixed. Would be good to fix this in 6u2 as well.

I have attached a sample test. Execute the sample test. A frame will open up with 2 buttons. Click on any of the buttons. A file dialog will be shown. Press ALT+TAB. If you see an extra icon on the window list for the FileDialog, the bug is reproduced.

EVALUATION Another small addition. After the fix for this bug, all the Java modal dialogs now behave like Windows modal dialogs: only the dialog's icon is visible in the ALT+TAB list, while all the blocked windows are not shown. Icons in the taskbar are unchanged: all the frames and parentless dialogs are visible there.

19-06-2007

EVALUATION I have found only two ways to remove an icon from the task list (ALT+TAB list): disable a window or use WS_EX_NOACTIVATE for it. Disabling windows is how AWT modality was implemented prior to 6.0, and it had several disadvantages. For example, when a blocked window is clicked, we need to raise its blocker dialog to front, however is the window is disabled, we don't receive mouse events for it. That's why I have decided to use WS_EX_NOACTIVATE exstyle. All the blocked windows are now have this style set when blocked, and reset its value when unblocked. Still, I found a serious problem with using this exstyle. When a dialog is being hidden, we explicitly activate some other AWT window, otherwise Windows can activate any other application. This activation is performed from AwtDialog::ModalActivateNextWindow method by a search for all the visible, enabled, focusable windows and eframes. This method works fine with a single exception: parentless native (file/print/page) dialogs. For these dialogs, as I have found, the time of calling this method is too late, after Windows has already activated some another application (as all the blocked Java windows have WS_EX_NOACTIVATE exstyle, Windows can't activate any of them). The right place of this call is WM_COMMAND/IDCANCEL or WM_NOTIFY/CDN_FILEOK notifications for file dialogs and WM_COMMAND/IDOK or WM_COMMAND/IDCANCEL for print and page dialogs. To handle these events we have to subclass the dialog's top-level window, which looks like a common Win32 task, though.

19-06-2007

Relates :	JDK-6572263 - PIT:FileDialog minimized to taskbar(through 'Show Desktop')selecting the fileDialog using windowList
Relates :	JDK-6573198 - PIT: NullPointerException when trying print-to-file from a native print dialog, Win32
Relates :	JDK-6714829 - REGRESSION: Wrong modal dialog activated after child closed, causes freeze
Relates :	JDK-6491273 - Print and Page dialogs are shown in the taskbar, on Windows
Relates :	JDK-6488834 - REG: An extra icon is created on the taskbar when a native dialog is opened, Win32