<div dir="ltr"><div><br></div><div><br></div>I cannot reproduce the problem with a build from Dmitry and with a clean build with a patch for jdk8u-dev from Dmitry.<div><br></div><div>Thank you,</div><div> Denis.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 5, 2016 at 2:59 PM, Denis Fokin <span dir="ltr"><<a href="mailto:denis.fokin@gmail.com" target="_blank">denis.fokin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi AWT team,</div><div><br></div>I used the next test to reproduce the problem <div><br></div><div>===== OwnedWindowTest.java ======</div><div><br></div><div><div>public class OwnedWindowTest {</div><div> public static void main(String[] args) {</div><div> SwingUtilities.invokeLater(new Runnable() {</div><div> @Override</div><div> public void run() {</div><div> final JFrame jFrame = new JFrame("Owner frame");</div><div><br></div><div> jFrame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);</div><div> jFrame.setSize(new Dimension(500,500));</div><div><br></div><div> final JDialog jDialog = new JDialog(jFrame, "Owned dialog", false);</div><div> jDialog.setSize(new Dimension(200,200));</div><div><br></div><div> jFrame.setVisible(true);</div><div><br></div><div> jDialog.setVisible(true);</div><div> }</div><div> });</div><div><br></div><div> }</div><div>}</div><div><br></div><div>======== End of OwnedWindowTest.java ======</div><div><br></div><div><br></div><div>My configuration:</div><div><br></div><div><div>Hardware Overview:</div><div><br></div><div> Model Name:<span style="white-space:pre-wrap"> </span>MacBook Pro</div><div> Model Identifier:<span style="white-space:pre-wrap"> </span>MacBookPro10,2</div><div> Processor Name:<span style="white-space:pre-wrap"> </span>Intel Core i5</div><div> Processor Speed:<span style="white-space:pre-wrap"> </span>2,6 GHz</div><div> Number of Processors:<span style="white-space:pre-wrap"> </span>1</div><div> Total Number of Cores:<span style="white-space:pre-wrap"> </span>2</div><div> L2 Cache (per Core):<span style="white-space:pre-wrap"> </span>256 KB</div><div> L3 Cache:<span style="white-space:pre-wrap"> </span>3 MB</div><div> Memory:<span style="white-space:pre-wrap"> </span>8 GB</div><div> Boot ROM Version:<span style="white-space:pre-wrap"> </span>MBP102.0106.B0A</div><div> SMC Version (system):<span style="white-space:pre-wrap"> </span>2.6f59</div><div> Sudden Motion Sensor:<br></div><div> State:<span style="white-space:pre-wrap"> </span>Enabled</div></div><div><br></div><div>OS El Capitan </div><div>Version 10.11.4</div><div><br></div><div>External Display:</div><div><br></div><div>Apple Thunderbolt Display<br></div><div>27-inch (2560 x 1440)<br></div><div>Intel HD Graphics 4000 1536 MB graphics<br></div><div><br></div><div>Thank you,</div><div> Denis.</div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 4:26 PM, Denis Fokin <span dir="ltr"><<a href="mailto:denis.fokin@gmail.com" target="_blank">denis.fokin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi AWT team,</div><div><br></div><div>thank you for the great effort in resolving the issue.</div><div><br></div>I tried the fix (webrev.02) with the latest jdk8u-dev repository.<div><br></div><div>I have found the next regressions:</div><div><br></div><div>1. Run a test case. JFrame + owned JDialog. Move the frame to the secondary monitor. Move the dialog to the main dialog. Click on the frame title. Press and hold dialog title. The dialog jumps on the secondary screen. Release the mouse button. The dialog jumps to the main screen.</div><div><br></div><div>2. Sometimes, the dialog does not return back to the secondary screen.<br></div><div><br></div><div>3. I do not remember exact scenario, but once, the dialog became minified (folded into title). </div><div><br></div><div><br></div><div>It looks like the fix require further improvement.</div><div><br></div><div>I personally, do not like all these add/remove machinery. Keeping z-order model in awt and placing all windows in the NSNormalWindowLevel<br> level seems the best solution to me. Otherwise, we will get constant regressions.</div><div><br></div><div>Thank you,</div><div> Denis.</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 4:24 PM, dmitry markov <span dir="ltr"><<a href="mailto:dmitry.markov@oracle.com" target="_blank">dmitry.markov@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Anton,<br>
<br>
Let me clarify the implementation of orderChilds() function. It is
responsible for proper windows ordering, (i.e. child windows should
be always placed/ordered above their parents or owners; a
parent/owner window should not overlap its children during sizing or
moving operations).<br>
<br>
Usually all Java windows/frames/dialogs have the normal level. <br>
<br>
When a window receives focus, (i.e. becomes 'main/key' window), we
will look for all its children and move them to the floating level.
According to Cocoa documentation: floating windows always appear in
front of normal-level windows, (see
<a href="https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/#//apple_ref/occ/instp/NSWindow/level" target="_blank">https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/#//apple_ref/occ/instp/NSWindow/level</a>).
Also we explicitly order each children above its nearest owner using
orderWindow() function, see code fragment below:<br>
<pre><font color="#3333ff"><span>[window orderWindow:NSWindowAbove relativeTo:[owner.nsWindow windowNumber]];</span></font></pre>
When a window loses focus, (i.e. resigns 'main/key' window status),
we will look for its children and move them back to the normal
level. And of course we order each child window above its nearest
parent using orderWindow().<br>
<br>
Please note: orderChilds() function changes window level only for
child windows of current 'main/key' window, (i.e. focus owner); the
window level of 'main/key' is not affected.<br>
<br>
So for your example: A<-B<-C relationship and A,C,B sequence
(assume A has just received focus) we will get something following:<br>
1. A stays at the normal window level<br>
2. C is moved to the floating level and ordered above B<br>
3. B is moved to the floating level and ordered above A (actually
ordering operation does not matter here since A and B are located at
different levels)<br>
4. C and B are displayed in front of A due to different window
levels; C is appeared above B due to ordering call at step 2<br>
<br>
I agree the comments inside orderChilds() are not clear and may
confuse. I updated the fix, new version is located at
<a href="http://cr.openjdk.java.net/~dmarkov/8080729/webrev.02/" target="_blank">http://cr.openjdk.java.net/~dmarkov/8080729/webrev.02/</a><br>
Summary of change:<br>
- Renamed orderChilds() and iconifyChilds() to orderChildWindows()
and iconifyChildWindows() accordingly<br>
- Added some comments to orderChildWindows()<br>
<br>
Thanks,<br>
Dmitry<div><div><br>
<br>
<div>On 28/04/2016 11:40, Anton Tarasov
wrote:<br>
</div>
<blockquote type="cite">
Hi Dmitry,
<div><br>
</div>
<div>Honestly, I don’t clearly understand how it works
now.</div>
<div><br>
</div>
<div>With A<-B<-C relationship and A,C,B sequence:</div>
<div><br>
</div>
<div>1. C is ordered above B (we get: A-C-B)</div>
<div>2. B is ordered above A (we get: B-A-C)</div>
<div><br>
</div>
<div>So, C ordering is lost. Or I'm missing something?</div>
<div><br>
</div>
<div>Also, can you please clarify the following.</div>
<div><br>
</div>
<div>
<pre style="background-color:rgb(238,238,238)"><span style="color:blue">+ if (focus) {</span>
<span style="color:blue">+ // Place the child above the owner</span>
<span style="color:blue">+ [window setLevel:NSFloatingWindowLevel];</span>
<span style="color:blue">+ } else {</span>
<span style="color:blue">+ // Place the child to the owner's level</span>
<span style="color:blue">+ [window setLevel:NSNormalWindowLevel];</span>
<span style="color:blue">+ }</span></pre>
<div>Am I right that the reason you place the child to
the floating level is because the “main/key” window is there?
If so, then the comment is somewhat confusing. You don’t
really put the child above the owner with that call. With both
the calls you simply put the child to the owner’s level. Is
that correct?</div>
<div><br>
</div>
<div>And also, if you modify the code further, may be
you rename “Childs” in the new methods to “Children” or to
“ChildWindows”?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Anton.</div>
<div><br>
<div>
<blockquote type="cite">
<div>On 28 Apr 2016, at 10:06, dmitry markov <<a href="mailto:dmitry.markov@oracle.com" target="_blank">dmitry.markov@oracle.com</a>>
wrote:</div>
<br>
<div>Hi Anton,<br>
<br>
Thank you for your feedback. You are right, in some
cases B may be ordered above C and that is incorrect. I
have updated the fix to eliminate this. Now we order a
window above its nearest parent/owner, (i.e. B is
ordered above A, C is ordered above B).<br>
Please find new version here: <a href="http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.01/" target="_blank">http://cr.openjdk.java.net/~dmarkov/8080729/webrev.01/</a><br>
<br>
Thanks,<br>
Dmitry<br>
On 27/04/2016 13:46, Anton Tarasov wrote:<br>
<blockquote type="cite">Hi Dmitry,<br>
<br>
The fix looks fine to me, still I have some concern...<br>
<br>
Say, we have windows with the following relationship:
A<-B<-C (owner<-child). Then the ordering is
executed for A:<br>
<br>
- We’ve got a sequence: A, B, C.<br>
- A is skipped, B is ordered above A, C is ordered
above A<br>
<br>
Am I right that C will be ordered above B (as it
should be) eventually?<br>
<br>
Is that possible that we get a sequence: A, C, B? And
then B will be ordered above C which is incorrect?<br>
<br>
Thanks,<br>
Anton.<br>
<br>
<blockquote type="cite">On 25 Apr 2016, at
22:35, dmitry markov <<a href="mailto:dmitry.markov@oracle.com" target="_blank">dmitry.markov@oracle.com</a>>
wrote:<br>
<br>
Any volunteers to review the fix?<br>
<br>
Thanks in advance,<br>
Dmitry<br>
On 21/04/2016 10:21, dmitry markov wrote:<br>
<blockquote type="cite">Hello,<br>
<br>
Could you review the fix for jdk9, please?<br>
<br>
bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8080729" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8080729</a><br>
webrev: <a href="http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.00/" target="_blank">http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/</a><br>
<br>
Problem description:<br>
On OS X platform in dual monitor setup a child
window jumps to another monitor where a
parent/owner is displayed.<br>
<br>
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:<br>
<br>
"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."<br>
<br>
So negative visual effects such as jumping to
another monitor in multi-monitor case, etc. are
caused by usage of addChildWindow() and
removeChildWindow().<br>
<br>
Fix:<br>
Replace CWrapper.NSWindow.addChildWindow() and
CWrapper.NSWindow.removeChildWindow() calls with
CWrapper.NSWindow.orderWindow() in CPlatformWindow
and CWarningWindow classes.<br>
<br>
Add several new methods to AWTWindow.m:<br>
- iconifyChilds() is responsible for hiding or
showing child windows when parent/owner window is
miniaturized or de-miniaturized.<br>
- 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).<br>
- isJavaPlatformWindowVisible() checks visibility
of native window from Java layer perspective.<br>
<br>
Thanks,<br>
Dmitry<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>