<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Looks good.</p>
    <p>--Semyon<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 11/07/2017 06:59 PM, Alexander
      Zvegintsev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:f603d7bd-58a5-fea1-2f75-17c5b0412c92@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p>HI Semyon,<br>
      </p>
      <p>Please see my answer to Dmitry</p>
      <p> </p>
      <blockquote type="cite">
        <pre wrap="">Hi Dmitry,

>From my understanding JavaFX stage can't be easily integrated in JDK to support orderWindow() approach,

addChildWindow() is a native(and the simplest) way to maintain one window above other one, should be called only once.

IIUC the main concert of JDK-8080729 that child windows jumping to parent's display upon focus receiving, this is not an issue with current fix,

because addChildWindow() will be called only upon dialog creation in case of JavaFX-Swing interop.

Jump may happen if user want to create a child swing dialog on display other than JavaFX stage's one,

but such rare scenario can be easily workarounded on a user side by calling setLocation() right after setVisible() call.

So I would prefer to use addChildWindow() to make this fix as simple as possible.</pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">Thanks,
Alexander.</pre>
      <div class="moz-cite-prefix">On 08/11/2017 02:45, Semyon Sadetsky
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:bfa2bece-ba83-78de-3294-b64f2a33f06b@oracle.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        <p>Hi Alexander,<br>
        </p>
        <p>In CPlatformWindow.java change you used addChildWindow(), but
          we get rig of addChildWindow() in 8080729 and start to manage
          windows order on java side. Can you test that this change
          doesn't cause any ordering issues with modal and non-modal
          child and sibling windows on mac?<br>
        </p>
        --Semyon<br>
        <br>
        <div class="moz-cite-prefix">On 11/07/2017 10:11 AM, Alexander
          Zvegintsev wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:6fdb5231-5d5d-7336-f2c5-c463399aac63@oracle.com">
          <meta http-equiv="Content-Type" content="text/html;
            charset=utf-8">
          <p>Hi Sergey,</p>
          <p>I am not able to crash it on several platforms, except one
            case: <br>
          </p>
          <p>if we are terminating JavaFX application while EDT
            processing some long task. But it is unrelated to the fix
            and reproducible on current builds.</p>
          <p> I've filed a separate bug <a
              href="https://bugs.openjdk.java.net/browse/JDK-8190329"
              moz-do-not-send="true">JDK-8190329</a>.</p>
          <p> </p>
          <blockquote type="cite">Will the current fix cover the native
            dialogs like FileDialog/PrintDialog on linux and windows? </blockquote>
          It will not, Windows already fixed by <a
            moz-do-not-send="true"
            href="https://bugs.openjdk.java.net/browse/JDK-8088395">JDK-8088395</a>
          <p><br>
          </p>
          Test added:<br>
          <a class="moz-txt-link-freetext"
            href="http://cr.openjdk.java.net/%7Eazvegint/jdk/10/8185634/05/"
            moz-do-not-send="true">http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/05/</a>
          <pre class="moz-signature" cols="72">Thanks,
Alexander.</pre>
          <div class="moz-cite-prefix">On 13/10/2017 01:14, Sergey
            Bylokhov wrote:<br>
          </div>
          <blockquote type="cite"
            cite="mid:8013fec4-ca01-7701-bc15-2fce01f88ca0@oracle.com">Looks
            fine. <br>
            I am not sure but it looks like the fix has an assumption
            that the CPlatformWindow.setVisible() code will be executed
            on EDT/Appkit but it is not the case. This code can be
            executed on any thread(intentionally for crash), and it will
            be good to check that it works as expected by some stress
            test which will try to force the possible crash: 4 threads:
            <br>
             - show/dispose Swing Node <br>
             - show/dispose Dialog1/2/3 using different timeouts <br>
            <br>
            Will the current fix cover the native dialogs like
            FileDialog/PrintDialog on linux and windows? <br>
            <br>
            On 10/10/2017 13:54, Kevin Rushforth wrote: <br>
            <blockquote type="cite">Note that there is now a 04 version.
              <br>
              <br>
              It looks good to me, although someone more familiar with
              AWT should also check the AWT changes. <br>
              <br>
              We will need a test program for this (as a follow-on issue
              if not now). <br>
              <br>
              -- Kevin <br>
              <br>
              <br>
              Alexander Zvegintsev wrote: <br>
              <blockquote type="cite">Please review the updated version
                <br>
                <br>
                <a class="moz-txt-link-freetext"
                  href="http://cr.openjdk.java.net/%7Eazvegint/jdk/10/8185634/02/"
                  moz-do-not-send="true">http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/02/</a>
                <br>
                Now we are postponing actual window closing, it happens
                only after we ensure that native window pointer is valid
                on Swing side. <br>
                <br>
                Thanks, <br>
                Alexander. <br>
                <br>
                On 23/09/2017 08:01, Sergey Bylokhov wrote: <br>
                <blockquote type="cite">Hi, Alexander. <br>
                  How can we be sure that the parent frame will not be
                  disposed while we use a pointer? <br>
                  <br>
                  long ownerWindowPtr = peer.getOverridenWindowHandle();
                  <br>
                  <<<<< Dispose the peer <br>
                  if (ownerWindowPtr != 0) { <br>
                      //Place window above JavaFX stage <br>
                      CWrapper.NSWindow.addChildWindow( <br>
                      ownerWindowPtr, ptr,
                  CWrapper.NSWindow.NSWindowAbove); <br>
                  <<<<< Boom <br>
                  } <br>
                  <br>
                  <br>
                  On 9/21/17 22:56, Alexander Zvegintsev wrote: <br>
                  <blockquote type="cite">Hi Phil, <br>
                    <br>
                    Please review the updated fix with reflection
                    incorporated <br>
                    <a class="moz-txt-link-freetext"
                      href="http://cr.openjdk.java.net/%7Eazvegint/jdk/10/8185634/01/"
                      moz-do-not-send="true">http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/</a>
                    <br>
                    <br>
                    New issue created JDK-8187803 <a
                      class="moz-txt-link-rfc2396E"
                      href="https://bugs.openjdk.java.net/browse/JDK-8187803"
                      moz-do-not-send="true"><https://bugs.openjdk.java.net/browse/JDK-8187803></a>
                    as JDK counterpart of this issue. <br>
                    <br>
                    Thanks, <br>
                    Alexander. <br>
                    <br>
                    On 21/09/2017 22:25, Phil Race wrote: <br>
                    <blockquote type="cite">Some procedural comments : <br>
                      Since 90% of this is in AWT code, I'd have thought
                      awt-dev should be included here. <br>
                      I've added that list. <br>
                      <br>
                      And apart from needing separate bug ids, I don't
                      see why the bug below is confidential. <br>
                      <br>
                      <br>
                      I agree with what Kevin pointed out off-line that
                      as in the dialog case, the FX side <br>
                      of the code can use reflection and simply be a
                      harmless non-functional no-op <br>
                      if the SwingAccessor does not provide the new
                      method. <br>
                      <br>
                      BTW <br>
                      264 inline HWND GetOverridenHWnd() { return
                      m_overridenHwnd; } <br>
                      should be "dd" not "d". <br>
                      <br>
                      -phil. <br>
                      <br>
                      On 09/21/2017 03:38 AM, Alexander Zvegintsev
                      wrote: <br>
                      <blockquote type="cite">Hello, <br>
                        <br>
                        please review the fix <br>
                        <br>
                        <a class="moz-txt-link-freetext"
                          href="http://cr.openjdk.java.net/%7Eazvegint/jdk/10/8185634/00/"
                          moz-do-not-send="true">http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/</a>
                        <br>
                        <br>
                        for the issue <br>
                        <br>
                        <a class="moz-txt-link-freetext"
                          href="https://bugs.openjdk.java.net/browse/JDK-8185634"
                          moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8185634</a>
                        <br>
                        <br>
                      </blockquote>
                      <br>
                    </blockquote>
                    <br>
                  </blockquote>
                  <br>
                  <br>
                </blockquote>
                <br>
              </blockquote>
            </blockquote>
            <br>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>