JDK-7145768 : [macosx] Regression: failure in b11 of ModalDialogInFocusEventTest
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-02-15
  • Updated: 2012-04-04
  • Resolved: 2012-04-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u4 b18Fixed 8Fixed
Mac OS X 10.7.3 macmini4,1, also iMac
Regression test closed/java/awt/Focus/ModalDialogInFocusEventTest consistently fails with b11 on stage 3 or sometimes 4. 
Test does display 2 Frames, and on focus events of a first one it fires a modal Dialog. Failure occurs in b11 if that Frame is activated first of two.

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.