<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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>
  </body>
</html>