<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Please look at the updated version:<br>
    <br>
    <a moz-do-not-send="true" class="moz-txt-link-freetext"
      href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.5">http://cr.openjdk.java.net/~ant/6981400/webrev.6</a><br>
    <br>
    It contains the following changes:<br>
    <br>
    1.
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.udiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.udiff.html</a><br>
    <br>
    Comments updated.<br>
    <br>
    2.
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/java/awt/Component.java.udiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/java/awt/Component.java.udiff.html</a><br>
    <br>
    The method:<br>
    <br>
    <pre><span class="new">((MouseEvent)currentEvent).getComponent() </span></pre>
    <br>
    is called instead of getSource() in order to avoid "instanceof"
    check for non-component sources.<br>
    <br>
    3.
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/sun/awt/SunToolkit.java.udiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/sun/awt/SunToolkit.java.udiff.html</a><br>
    <br>
    AppContext is used to store window deactivation times to guarantee
    security.<br>
    <br>
    4.
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ant/6981400/webrev.6/test/java/awt/Focus/6981400/Test1.java.html">http://cr.openjdk.java.net/~ant/6981400/webrev.6/test/java/awt/Focus/6981400/Test1.java.html</a><br>
    <br>
    Focus events order check is suppressed for XToolkit where this
    functionality can't be implemented due to time-less native focus
    messages.<br>
    <br>
    Thanks,<br>
    Anton.<br>
    <br>
    On 05.07.2012 18:30, Anton V. Tarasov wrote:
    <blockquote cite="mid:4FF5A4F7.7020308@oracle.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-text-flowed" style="font-size: 16px;"
        lang="x-unicode">[I had to fix the links in the previous e-mail,
        replaced webrev.4 with webrev.5, sorry]<br>
        <br>
        Hi, <br>
        <br>
        Please review a fix for the CR: <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6981400">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6981400</a>
        <br>
        <br>
        Webrev: <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.5">http://cr.openjdk.java.net/~ant/6981400/webrev.5</a>
        <br>
        <br>
        The fix covers a number of issues and is an evaluated version of
        the fix originally integrated into jdk6. The scenario which
        reproduces <br>
        the referred problems looks pretty like the following: <br>
        <br>
        A frame with components. The first component is focused. In its
        focusLost(..) listener it performs some lengthy operation. <br>
        TAB key is pressed, say, 5 times. The first component loses
        focus, the lengthy operation begins which freezes EDT for a
        while. <br>
        At the same time, a user switches to some other window by
        Alt-TABĀ  and then switches back by another Alt-TAB. When the
        lengthy <br>
        operation is done, the user expects focus to be transferred
        through the components in order as if no toplevel switch has
        happened. <br>
        Alternatively, the toplevel switch could be done by a mouse
        click in a component of the other java toplevel and then by a
        click to the <br>
        title of the original frame. <br>
        <br>
        This may cause the following unexpected results: <br>
        <br>
        1) Focus doesn't go through all the 5 components (which 5 TABs
        should result in) but stops on, say, the 3rd one. <br>
        2) Components are being transferred in wrong order, say 2, 3, 2,
        4, 5, 6 instead of 2, 3, 4, 5, 6. <br>
        3) A menu of the original frame eventually gets activated
        (reproducible on MS Windows). <br>
        <br>
        Detailed description of why AWT behaves that way is quite
        lengthy &amp; tangled. It can be found in the CR. <br>
        Below I'll shortly comment the changes made. (The fix
        additionally contains changes not directly related to the 3
        problems mentioned above, <br>
        but those changes were introduced based on thorough testing with
        the focus regression test base and analysing the failures). <br>
        <br>
        1. Component.requestFocusHelper(..),
        Component.dispatchEventImpl(..), Container, Dialog, EventQueue <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/java/awt/Component.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html</a>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/java/awt/Container.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Container.java.sdiff.html</a>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/java/awt/Dialog.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Dialog.java.sdiff.html</a>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/java/awt/EventQueue.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/EventQueue.java.sdiff.html</a>
        <br>
        <br>
        A focus request, in order to set a type-ahead marker's time,
        uses the time stamp of the last dispatched <span
          class="moz-txt-underscore"><span class="moz-txt-tag">_</span>key<span
            class="moz-txt-tag">_</span></span> event. <br>
        A time stamp of a key event, which is put into the type-ahead
        queue, is not registered until the event is retrieved from the
        queue for normal dispatching. <br>
        This establishes strong dependence b/w type-ahead markers and
        the order in which key events are actually dispatched. <br>
        <br>
        2. Component.requestFocusHelper(..) <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/java/awt/Component.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html</a>
        <br>
        <br>
        As the comments say, a focus request following a mouse event is
        forced to be "in-window" focus requests. This is to make sure it
        won't re-activate the window <br>
        in case the window is inactive by the time the request takes its
        turn for processing. This type of deferred side effect of the
        mouse event may not be correctly <br>
        processed under "tough" conditions and should be dropped. <br>
        <br>
        3. LWComponentPeer, LWWindowPeer <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html</a>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html</a>
        <br>
        <br>
        A simple (not Frame/Dialog) window or an active but not focused
        Frame/Dialog should request window focus by mouse click right on
        dispatching of the mouse event <br>
        on the platform side, not after the event made the "platform
        -&gt; java -&gt; platform" cycle. <br>
        <br>
        4. LWWindowPeer.dispatchKeyEvent(..) <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html</a>
        <br>
        <br>
        This is actually a fix for 7157015 (which I'll close later). The
        bug affects behavior and troubles testing of the whole fix, so
        I'm including this code as dependent. <br>
        <br>
        5. XBaseWindow, XComponentPeer <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html</a>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/solaris/classes/sun/awt/X11/XComponentPeer.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XComponentPeer.java.sdiff.html</a>
        <br>
        <br>
        Similarly to (3), but for X11 implementation. Additionally,
        "actualFocusedWindow" reference, which is the most recent
        focused owned simple window, is reset because <br>
        a click in an owned window should deliver focus to that window,
        not to the most recently focused one. <br>
        <br>
        6. DefaultKeyboardFocusManager.repostIfFollowsKeyEvents(..) <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/java/awt/DefaultKeyboardFocusManager.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/DefaultKeyboardFocusManager.java.sdiff.html</a>
        <br>
        <br>
        (The change originally suggested by Oleg Pekhovskiy) Toplevel
        window focus events (WINDOW_GAINED_FOCUS/WINDOW_LOST_FOCUS)
        should not be processed <br>
        until the type-ahead queue, populated before the event of
        switching toplevel windows actually happened, is empty. The only
        we can do here is to repost the toplevel focus <br>
        events to the end of the EDT queue. <br>
        <br>
        7. KeyboardFocusManagerPeerImpl <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java.sdiff.html</a>
        <br>
        <br>
        The calls: <br>
        <br>
        SunToolkit.postPriorityEvent(fl); <br>
        <br>
        were originally wrong. This is an artefact of an old fix
        (5028014) that has been rolled out, but went into jdk7 (with
        6806217) by a mistake. <br>
        The focus events should not be sent in prioritized order here. <br>
        <br>
        8. TimedWindowEvent <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/sun/awt/TimedWindowEvent.java.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/TimedWindowEvent.java.html</a>
        <br>
        <br>
        A WindowEvent with a time stamp. <br>
        <br>
        9. SunToolkit <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/sun/awt/SunToolkit.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/SunToolkit.java.sdiff.html</a>
        <br>
        <br>
        WINDOW_LOST_FOCUS event's time stamp is registered. <br>
        <br>
        10. WindowsRootPaneUI <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.sdiff.html</a>
        <br>
        <br>
        Skip menu activating events which weren't processed in time
        (while the containing toplevel window is active). <br>
        <br>
        11. awt_Window.cpp <br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eant/6981400/webrev.4/src/windows/native/sun/windows/awt_Window.cpp.sdiff.html">http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/windows/native/sun/windows/awt_Window.cpp.sdiff.html</a>
        <br>
        <br>
        Window focus events are supplied with a time stamp. <br>
        <br>
        - - - <br>
        Thanks, <br>
        Anton. <br>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>