Jaime,

May I ask you to try the following fix (which is a one-line change) in your 
environment with e16-1.0.11?

http://cr.openjdk.java.net/~ant/8009224/webrev.0

Thanks,
Anton.

On 12.03.2013 0:03, Jaime Peñalba wrote:
Thank you,

Hope someone will take a look into it.


Regards,
Jaime.


2013/3/6 Alexander Zvegintsev <[email protected] <mailto:[email protected]>>

    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.




Reply via email to