<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,
    <br>
    <br>
    Please review fix for JDK9:
    <br>
    <br>
    bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8036915">https://bugs.openjdk.java.net/browse/JDK-8036915</a><br>
    webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ssadetsky/8036915/webrev.00/">http://cr.openjdk.java.net/~ssadetsky/8036915/webrev.00/</a><br>
    <br>
    The test scenario attached to the jira contains potential errors
    because Componet.getLocation() won't return the location at any
    moment of time.<br>
    Anyway a window location issue exists in Unity. The root cause is
    that
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    the real insets sent with the XA_NET_FRAME_EXTENTS event can be
    overridden by the "guessed" insets which are zero on Unity. So the
    returned location is increased by real insets while the real window
    location is correct.<br>
    Yet another issue I found in Unity is a window size issue which is
    also caused by the frame insets detection. The Unity WM doesn't
    provide the frame insets immediately and XA_NET_FRAME_EXTENTS event
    may come after the
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    ConfigureNotify event for the frame.<br>
    The solution proposes an adaptation of the existing frame insets
    request algorithm to the Unity WM so that makes it more stable.<br>
     <br>
    --Semyon<br>
    <br>
    <br>
  </body>
</html>