JDK-6613426 : two WM_TAKE_FOCUS messages on one mouse click in GNOME Metacity 2.16.0
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2007-10-05
  • Updated: 2013-03-14
  • Resolved: 2011-05-18
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.
JDK 7
7 b27Fixed
Related Reports
Relates :  
JDK-8009224 - JDK7 looses focus under e16 window manager
Description
OS: Linux Fedora Core 6, GNOME Metacity 2.16.0 (not reproducible on KDE)
JDK: 7.0 b18

There's an owner Frame F1 and its owned Window with a button insude. There's also
another Frame F2. I'm clicking the button - the Window becomes the focused window,
F1 becomes the active window. Then I'm clicking F2, it gains focus, and then I'm
clicking F1's title.

EXPECTED:
The button in the Window should gain focus as it had it before.

ACTUAL:
The button gains focus, but then F1 immediately steals it.

It can be reproduced with the following regression test:
test/closed/java/awt/Focus/ActualFocusWindowRetaining/ActualFocusWindowRetaining.java
Comments
SUGGESTED FIX ------- XDecoratedPeer.java ------- *** /tmp/sccs.cAaOut Tue Oct 9 17:32:55 2007 --- XDecoratedPeer.java Tue Oct 9 17:31:56 2007 *************** *** 974,983 **** --- 974,993 ---- } } private void handleWmTakeFocus(XClientMessageEvent cl) { focusLog.log(Level.FINE, "WM_TAKE_FOCUS on {0}", new Object[]{this}); + // A workaround to Metacity issue (see 6613426). + // The first check is to skip redundant WM_TAKE_FOCUS on click + // in a focused frame. The second check is to allow requesting focus + // on click in a frame when its owned window is currently focused. + if (this == getNativeFocusedWindowPeer() && + target == XKeyboardFocusManagerPeer.getCurrentNativeFocusedWindow()) + { + focusLog.fine("The window is already focused, skipping."); + return; + } requestWindowFocus(cl.get_data(1), true); } /** * Requests focus to this decorated top-level by requesting X input focus
26-03-2008
EVALUATION A bug is filed against Metacity 2.16.x: http://bugzilla.gnome.org/show_bug.cgi?id=485016 Bug 485016 ��� Two WM_TAKE_FOCUS messages on single click in the title of a window.
09-10-2007
EVALUATION The problem is as follows. When I'm clicking F1's title it receives WM_TAKE_FOCUS msg. Focus is requested on F1 (XDecoratedPeer.requestWindowFocus() method). Native focus is set to the focus proxy window (a child of F1). After it receives FocusIn the window manager again sends F1 WM_TAKE_FOCUS msg. The second WM_TAKE_FOCUS causes the Frame to request focus again. By this time the owned Window is already sent WINDOW_GAINED_FOCUS and the actualFocusedWindow field of the Frame is set to null. Thus, it requests focus on itself. A solution would be to reject requesting focus on receiving WM_TAKE_FOCUS in case the Frame is already the native focused window.
05-10-2007