Looks like someone already fixed the bug in e16 http://git.enlightenment.org/e16/e16.git/commit/?id=ba29ecf04ea3d6a8b4eb20f128b9daa4761e8988
Sorry for all the trouble and thanks for the support :) Regards, Jaime. 2013/3/15 Anton V. Tarasov <anton.tara...@oracle.com> > 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 <alexander.zvegint...@oracle.com> > >> 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. >> >> >> > >
