<AWT Dev> [Bug 100300] JDK7 looses focus under e16 window manager

[Alexander Zvegintsev]

Hi Jaime,

I have filed this bug as
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009224

Thanks,

Alexander.

On 02/27/2013 07:45 PM, Jaime Peñalba wrote:
> 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.
>
>
> Below is a patch for the dirty workaround:
>
>     ---
>     openjdk/jdk/src/solaris/classes/sun/awt/X11/XContentWindow.java
>     2012-08-29 01:15:20.000000000 +0200
>     +++
>     openjdk7-mod/jdk/src/solaris/classes/sun/awt/X11/XContentWindow.java
>     2013-02-21 00:20:45.174245553 +0100
>     @@ -184,4 +184,33 @@
>          public String toString() {
>              return getClass().getName() + "[" + getBounds() + "]";
>          }
>     +
>     +    public void dispatchEvent(XEvent ev) {
>     +        int type = ev.get_type();
>     +
>     +        switch (type)
>     +        {
>     +          case XConstants.FocusIn:
>     +          case XConstants.FocusOut:
>     +              System.out.println("DISPATCHING FOCUS ON CONTENT
>     WINDOW");
>     +              handleFocusEvent(ev);
>     +              break;
>     +        }
>     +        super.dispatchEvent(ev);
>     +    }
>     +
>     +    public void handleFocusEvent(XEvent xev) {
>     +        int type = xev.get_type();
>     +
>     +        switch (type)
>     +        {
>     +          case XConstants.FocusIn:
>     +          case XConstants.FocusOut:
>     +              System.out.println("HANDLING FOCUS EVENT ON CONTENT
>     WINDOW");
>     +              break;
>     +        }
>     +
>     +        parentFrame.handleFocusEvent(xev);
>     +    }
>     +
>      }
>
>
>
> This bug is really annoying me as I cannot use JDK7 under e16. Does 
> anyone have idea why the XcontentWindow is raising the event?
>
>
> Regards,
> Jaime.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20130306/21815255/attachment.html