<AWT Dev> [Bug 100300] JDK7 looses focus under e16 window manager
Anton V. Tarasov
anton.tarasov at oracle.com
Wed Jun 5 07:11:27 PDT 2013
On 01.06.2013 11:39, Jaime Peñalba wrote:
> Looks like someone already fixed the bug in e16
> http://git.enlightenment.org/e16/e16.git/commit/?id=ba29ecf04ea3d6a8b4eb20f128b9daa4761e8988
Wow, very good! Thank you for the info! =)
>
> Sorry for all the trouble and thanks for the support :)
You're welcome!
Anyway, the fix is in the jdk8 workspace (because the problem affected some other WMs as well).
Thanks,
Anton.
>
>
> Regards,
> Jaime.
>
>
> 2013/3/15 Anton V. Tarasov <anton.tarasov at oracle.com <mailto:anton.tarasov at 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
> <http://cr.openjdk.java.net/%7Eant/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.zvegintsev at oracle.com
>> <mailto:alexander.zvegintsev at 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.
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20130605/e5d567cb/attachment-0001.html
More information about the awt-dev
mailing list