JDK-8009224 : JDK7 looses focus under e16 window manager
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2013-02-28
  • Updated: 2013-05-22
  • Resolved: 2013-04-10
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 8
8-poolResolved
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Subject:     <AWT Dev> [Bug 100300] JDK7 looses focus under e16 window manager
Date:     Wed, 27 Feb 2013 16:45:11 +0100
From:     Jaime Pe��alba <jpenalbae@gmail.com>
To:     awt-dev@openjdk.java.net


Last week I reported the following bug:
https://bugs.openjdk.java.net/show_bug.cgi?id=100300 but Anthony Petrov
suggested me to bring the topic here.

------------------------------------------------------------------------------------------------------------------------------

First of all this bug has been introduced on JDK7 as JDK6 works
perfectly under
enlightenmenet e16 window manager.

To reproduce this bug just run any java application under the window manager
e16 using JDK7. All my tests have been done using version "e16-1.0.11" and
openjdk-7u6-fcs-src-b24-28_aug_2012.zip. Here are the e16 binaries which I
compiled and which I'm using:
http://www.painsec.com/writeups/resources/misc/e16-1.0.11-bin.tar.bz2

Steps to reproduce the bug:
  - Run any java swing/awt application under e16-1.0.11 window manager.
  - Change focus to another window/application.
  - Return focus to the java application.
  - It will no longer allow you to write on any text field.

The problem is that once the java window loose the focus it never regains it
again loosing the ability to input text although mouse clicks still work
fine.

I'm not used to X11 programming neither to hacking the OpenJDK, anyway
trying
to hunt the bug I found that a proper focus event is handled in the
following
manner:

             at
    sun.awt.X11.XWindowPeer.handleFocusEvent(XWindowPeer.java:806)
             at
    sun.awt.X11.XDecoratedPeer.handleFocusEvent(XDecoratedPeer.java:225)
             at

sun.awt.X11.XFocusProxyWindow.handleFocusEvent(XFocusProxyWindow.java:77)
             at
    sun.awt.X11.XFocusProxyWindow.dispatchEvent(XFocusProxyWindow.java:70)
             at
    sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1066)
             at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:577)
             at sun.awt.X11.XToolkit.run(XToolkit.java:686)
             at sun.awt.X11.XToolkit.run(XToolkit.java:607)
             at java.lang.Thread.run(Thread.java:722)



But under e16 the event gets lost at:

             at
    sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1066)
             at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:577)
             at sun.awt.X11.XToolkit.run(XToolkit.java:686)
             at sun.awt.X11.XToolkit.run(XToolkit.java:607



The code sun.awt.X11.XBaseWindow.dispatchToWindow is as follows

         /**
          * Dispatches event to the grab Window or event source window
    depending
          * on whether the grab is active and on the event type
          */
         static void dispatchToWindow(XEvent ev) {
             XBaseWindow target = XAwtState.getGrabWindow();
             if (target == null || !isGrabbedEvent(ev, target)) {
                 target =
    XToolkit.windowToXWindow(ev.get_xany().get_window());
             }
             if (target != null && target.checkInitialised()) {
                 target.dispatchEvent(ev);
             }
         }


After some tinkering I discovered that the obtained "XBaseWindow target"
points
to a "XContentWindow" object instead of a "XFocusProxyWindow" object as
expected, and the "XContentWindow" class extending "XWindow" doesn't have a
"dispatchEvent()" method so the event gets lost forever.

I don't know why XContentWindow is catching the event instead of
XFocusProxyWindow, looks like the real bug is because of that, but I didn't
managed to trace why the event is being associated with XContentWindow.

As an ugly workaround I implemented the "dispatchEvent()" and
"handleFocusEvent()" under the "XContentWindow" class calling to
"parentFrame.handleFocusEvent(xev)" where parentFrame should be the real
main
window (XDecoratedPeer). This dirty hack works, but I don't think that
this is
the way to do it, as JDK6 works fine without implementing these methods
under
the "XContentWindow" class.

Comments
suggested fix: http://cr.openjdk.java.net/~ant/8009224/webrev.0 test/java/awt/Focus/ActualFocusWindowRetaining/ActualFocusWindowRetaining.java (mentioned in 6613426) works with it.
14-03-2013

I checked it with e16 of some earlier version - 1.0.0-3.1. Indeed, there's the problem you've pointed. I've managed to find the fix which caused the regression. It's CR 6613426, the fix was integrated into jdk7 b27. That was a workaround for some Metacity issue [1]. However, what I'm seeing with e16 also doesn't meet my expectations. Namely, it seems like e16 doesn't follow "Gloabl Active" focus model behavior specification [2], which assumes that a window manager doesn't set focus to a window, but only notifies it with WM_TAKE_FOCUS (for example, when the window is clicked). But a focus log (sun.awt.X11.level=ALL) shows that the frame is natively focused right after it receives WM_TAKE_FOCUS which prevents the frame from normal activation due to the fix for 6613426. What I can suggest is another workaround - add if (XWM.getWMID() != XWM.ENLIGHTEN_WM) condition to the fix. [1] https://bugzilla.gnome.org/show_bug.cgi?id=485016 [2] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
14-03-2013