<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 class="" style="white-space:pre">      </span>MacBook Pro</div><div>  Model Identifier:<span class="" style="white-space:pre">    </span>MacBookPro10,2</div><div>  Processor Name:<span class="" style="white-space:pre">   </span>Intel Core i5</div><div>  Processor Speed:<span class="" style="white-space:pre">   </span>2,6 GHz</div><div>  Number of Processors:<span class="" style="white-space:pre">    </span>1</div><div>  Total Number of Cores:<span class="" style="white-space:pre"> </span>2</div><div>  L2 Cache (per Core):<span class="" style="white-space:pre">   </span>256 KB</div><div>  L3 Cache:<span class="" style="white-space:pre"> </span>3 MB</div><div>  Memory:<span class="" style="white-space:pre">     </span>8 GB</div><div>  Boot ROM Version:<span class="" style="white-space:pre">   </span>MBP102.0106.B0A</div><div>  SMC Version (system):<span class="" style="white-space:pre">    </span>2.6f59</div><div>  Sudden Motion Sensor:<br></div><div>  State:<span class="" style="white-space:pre">   </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 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 class=""><div class="h5"><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>