<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Alexey & Dmitry,<br>
    <br>
    The bug may be a Mac specific issue.<br>
    Can you try to replace in the LWComponentPeer::requestFocus<br>
    <br>
    960                boolean res =
    parentPeer.requestWindowFocus(cause);<br>
    with<br>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
                    KeyboardFocusManagerPeer kfmPeer =
    LWKeyboardFocusManagerPeer.getInstance();<br>
                    Component focusOwner =
    kfmPeer.getCurrentFocusedWindow();<br>
                    boolean res = parentPeer.getTarget() == focusOwner
    || parentPeer.requestWindowFocus(cause); <br>
    <br>
    and run the test without the current fix on jdk10?<br>
    <br>
    --Semyon  <br>
    <br>
    <div class="moz-cite-prefix">On 9/27/2017 1:45 PM, Alexey Ivanov
      wrote:<br>
    </div>
    <blockquote
      cite="mid:66013f60-50d5-13cf-9e05-bce786295e9d@oracle.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Hi Semyon,<br>
      <br>
      You're right: the test does not fail for me too on Windows 10
      using jdk10. At the same time, I can reproduce the problem using
      focus8Test.jar attached to the bug [1]. However, it's harder to
      reproduce the issue using jdk10 or jdk9. It takes more attempts
      than with jdk8.<br>
      <br>
      <br>
      I could reproduce the problem on Windows 7 and Windows 10.<br>
      <br>
      However, if I switch the theme to Windows Basic or Windows Classic
      in Windows 7, the issue cannot be reproduced any more. It looks as
      if it's related to window animation when a new dialog appears and
      disappears. If the dialog appears on the screen for a longer
      while, the test does not fail either.<br>
      <br>
      <br>
      Regards,<br>
      Alexey<br>
      <br>
      [1] <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-8155197">https://bugs.openjdk.java.net/browse/JDK-8155197</a><br>
      <br>
      <div class="moz-cite-prefix">On 26/09/2017 23:46, Semyon Sadetsky
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:59CAD8C5.3040800@oracle.com">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        Hi Dmitry,<br>
        <br>
        <div class="moz-cite-prefix">On 9/26/2017 1:56 AM, Dmitry Markov
          wrote:<br>
        </div>
        <blockquote
          cite="mid:8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com"
          type="cite">
          <pre wrap="">Hi Semyon,

Please find my answer inline.

Thanks,
Dmitry
</pre>
          <blockquote type="cite">
            <pre wrap="">On 25 Sep 2017, at 22:26, Semyon Sadetsky <a class="moz-txt-link-rfc2396E" href="mailto:semyon.sadetsky@oracle.com" moz-do-not-send="true"><semyon.sadetsky@oracle.com></a> wrote:

Hi Dmitry,


On 09/25/2017 01:09 PM, Dmitry Markov wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">Hi Semyon,

This issue and the problem addressed by 8139218 and 8159432 are slightly different. This one is still reproducible on latest 9 and 10 builds using the test case attached to the bug or regression test provided with the fix.
</pre>
            </blockquote>
            <pre wrap="">I couldn't get the test failed on 9 and 10. But I only tried it on Ubuntu. Is the issue a platform dependent?
</pre>
          </blockquote>
          <pre wrap="">I was able to reproduce the issue on Windows and Mac OSX. I didn’t test Linux, but I guess it is present there too.
Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to reproduce the issue.</pre>
        </blockquote>
        Not sure that 3D may change focus behavior. But I did not uses
        physical Ubuntu to test.<br>
        I also couldn't get the test failed on Windows platform after 10
        attempts:<br>
        <br>
        ssadetsk@SSADETSK-LAP1 /data/projects/client10/jdk<br>
        $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg
        -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr
        test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`;
        done<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        Test: extra argument ‘passed:’<br>
        <br>
        <blockquote
          cite="mid:8706045C-F3E2-485D-9807-4F0859ACC7A3@oracle.com"
          type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">The problem takes place when we restore focus to a component and its parent window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore focus synchronously). If the parent window loses the focus during this invocation, focus request will fail and focus target will be shifted to next in focus traversal cycle. This case is not covered by the changes introduced by 8139218 and 8159432.
</pre>
            </blockquote>
            <pre wrap="">I see. What may prevent to set the input focus synchronously? Since the native window already has the focus this should be very deterministic.
</pre>
          </blockquote>
          <pre wrap="">The native window loses focus if another window or dialog is displayed. Proposed fix is intended for the following case:
The native window owns focus and we set the focus to one of its child components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). At the same time another window/dialog pops up, requestFocus() fails because the native parent window is not the focus owner any more and we shift focus target to next component.</pre>
        </blockquote>
        <meta http-equiv="content-type" content="text/html;
          charset=utf-8">
        <pre wrap="">The requestFocus() calls the requestFocusHelper() which has several outcomes that returns "false". Which one of them should be involved?

--Semyon
</pre>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>