SUGGESTED FIX

http://cr.openjdk.java.net/~ant/7145768/
                                     

EVALUATION

When the first frame is shown and focused, WINDOW_GAINED_FOCUS is posted to it. When the evene is dispatched by DKFM, focus is requested on the most-recent-focus-owner in the frame via calling requestFocusInWindow(). The method (the call stack it produces) looks for the "native focused window" which is returned by KeyboardFocusManagerPeer implementation as a reference to the java peer window object. The latter is set up when corresponding native window gains focus, on toolkit thread. So there may be a time slot when native focused window changes, but KFMPeer still keeps reference to the previous focused window object, on EDT.

Back to requestFocusInWindow(). If allows requests "in window" and denies requests which require focused window change. In case of the test, the request is allowed when real native focused window changes to the second frame, when it's just shown. The latter causes the first frame to regain native focus.

A possible solution is to additionally check if current focused window retained by KFMPeer is natively focused at the moment of decision whether to allow focus request or don't.
                                     

EVALUATION

The test shows two frames, then it shows a modal dialog from a focus listener (the type of event depends on a test stage), then closes the dialog and hides the frames. The process repeats on the next stage. This way the test checks that showing a dialog doesn't hang the app.

Sometimes, when two frames are shown in a raw, I see window focus events generated for the first frame, then for the second frame and then again for the first frame. At the same time, the second frame remains visually active. Thus, we face java & native focus unsynchronized. After all, the test clicks the second frame & waits for appropriate focus events but nothing is generated as the frame is natively active.