JDK-8087853 : Win: Modal Stage slides under a Popup (with same owner stage) that is created before, on windows.
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 7u6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2012-06-07
  • Updated: 2018-09-05
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.
Other
tbdUnresolved
Related Reports
Duplicate :  
JDK-8124542 - ColorPickerPalette window stays on top when Custom Colors window is opened and user has switched to another application
Relates :  
JDK-8112905 - PopupControls (ContextMenu, Tooltip) not shown in front of JFXPanel.
Relates :  
JDK-8088309 - Win: Popup should move to front/back when it's owning window does
Relates :  
JDK-8124542 - ColorPickerPalette window stays on top when Custom Colors window is opened and user has switched to another application
Relates :  
JDK-8088778 - Win: Popups and Context Menus stay in foreground when debugging
Relates :  
JDK-8088624 - Win: Tooltip popup on causes its owner window to come front if it is behind another window.
Description
Run HelloColorPicker 
Click to open the ColorPalette Popup
Click on custom color link to open custom color dialog.
Move the dialog ( modal stage) over the popup.

Observe it slides under the popup.
Note both the Popup and modal stage have the same owner - the main stage; Popup is created first and then the modal stage.

On Mac platform however, it slides over.
Comments
Downgrading to P4 and targeting to Van Ness, since it's not a common use case, and no simple solution for this problem is known.
10-10-2013
Changed Custom Color Dialog's owner to be Palette popup instead of the main stage. This does fix the problem when sliding.
25-03-2013
SQE / OK
18-07-2012
2.2 defer request: simple workaround exists + not a typical case (strange window hierarchy).
17-07-2012
I've added the following lines after showing an unfocusable window: + + ::SetWindowLong(hWnd, GWL_EXSTYLE, ::GetWindowLong(hWnd, GWL_EXSTYLE) & ~WS_EX_TOPMOST); + ::SetWindowPos(hWnd, NULL, 0, 0, 0, 0, + SWP_FRAMECHANGED | SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOOWNERZORDER | SWP_NOREPOSITION | SWP_NOSIZE | SWP_NOZORDER); + But this simple resetting of the WS_EX_TOPMOST style didn't help. I'm reassigning this issue to the author of the original fix for RT-14197 for further evaluation. @Paru: please consider making the palette popup an owner for the Custom Color dialog. This looks logical, and should resolve the issue for Controls.
09-06-2012
This is a regression of RT-14197. Specifically, the way we show unfocusable windows by first making them TOPMOST, and then simply TOP (see WinWindow._setVisible() implementation). The popup is an unfocusable window, and it looks like it remains to be on top of everything. It looks like once a popup window is shown, only other popup windows may appear above it in the z-order. Other types of windows will remain below it.
08-06-2012
Yes, this looks like a bug, and we'll try to fix it. A workaround is to make the popup an owner for the Custom Color dialog. This makes sense from logical perspective too, since the dialog is really a child of the palette, not a window in which the color picker control is located.
08-06-2012