Any volunteers to review the fix?
Thanks in advance,
Dmitry
On 21/04/2016 10:21, dmitry markov wrote:
Hello,
Could you review the fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8080729
webrev: http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/
Problem description:
On OS X platform in dual monitor setup a child window jumps to another
monitor where a parent/owner is displayed.
In CPlatformWindow and CWarningWindow classes we use
CWrapper.NSWindow.addChildWindow() and
CWrapper.NSWindow.removeChildWindow() during parent-child relationship
processing (see setVisible() and orderAboveSiblings() for details).
The methods addChildWindow() and removeChildWindow() invoke
corresponding Cocoa API (see NSWindow in Cocoa framework). According
to Cocoa documentation:
"After a window is added as a child of parent window, it is maintained
in relative position indicated by ordering mode for subsequent
ordering operations involving either window. While this attachment is
active, moving child window will not cause parent window to move, but
moving the parent window will cause child window to move."
So negative visual effects such as jumping to another monitor in
multi-monitor case, etc. are caused by usage of addChildWindow() and
removeChildWindow().
Fix:
Replace CWrapper.NSWindow.addChildWindow() and
CWrapper.NSWindow.removeChildWindow() calls with
CWrapper.NSWindow.orderWindow() in CPlatformWindow and CWarningWindow
classes.
Add several new methods to AWTWindow.m:
- iconifyChilds() is responsible for hiding or showing child windows
when parent/owner window is miniaturized or de-miniaturized.
- orderChilds() is responsible for child windows ordering. Order
operation is based on the current focus state of owner window, (e.g.
if owner window is focused, all its child should be ordered above it).
- isJavaPlatformWindowVisible() checks visibility of native window
from Java layer perspective.
Thanks,
Dmitry
