Thank you, Hope someone will take a look into it.
Regards, Jaime. 2013/3/6 Alexander Zvegintsev <[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. > > >
