<AWT Dev> <Swing Dev> jdk17 on x11: keyboard focus consistently broken on some window managers
Artem.Ananiev at Sun.COM
Wed Jun 30 01:54:30 PDT 2010
On 6/30/2010 12:29 AM, Peter Schuller wrote:
> I am not certain whether this is the right list to post to since the
> problem is likely related to the native integration of the windowing
> toolkit rather than Swing itself, but I didn't see a more obviously
> correct choice in the list of mailing lists.
awt-dev is the right alias for all the issues like that. It's AWT
library that provides the integration with the windowing subsystem.
> The purpose of this post is to find out whether there is a known issue
> and whether there is a fix expected for JDK 1.7 release. If not,
> whether anyone has ideas or pointers as to what the likely problem is
> (I'd like to try to look into it but realistically I will have limited
> time to spend on it so any suggestions would be appreciated).
> I have been trying to run Swing applications with JDK 1.7 (snapshot
> rels or the bsd-port branch in hg depending on platform) for the
> massively increased performance (render extension, etc). However I
> have consistently seen a keyboard focus problem on several platforms
> and window managers and sticking now over some time (i.e., it's not
> specific to some particular snapshot release of JDK 1.7).
> The manifestation is that keyboard input (for example, trying to enter
> text into text fields), has no user-visible effect. The cursor is
> lacking text fields, and hitting keys have no effect. This triggers
> even on trivial cases like the Notepad JFC demo, as well as larger
> apps like IntelliJ. The effect is that it is essentially impossible to
> use the keyboard in Swing applications (plain AWT untested), at all
> (it is not triggering sporadically, it is happening essentially all
> the time as far as I can tell).
> I have tried it on the following combinations of OS/window managers:
> * succeeds (works): linux x86-64/kde (debian squeeze)
> * fails: linux x86-64/stumpwm (debian squeeze)
> * fails: freebsd x86-64/icewm
> * fails: freebsd x86-64/stumpwm
> * fails: freebsd x86-64/xmonad
> Now, I know stumpwm/xmonad are not entirely mainstream and the
> non-reparenting nature of them has been an issue with Java, but
> 'icewm' does not feel very obscure to me.
The list of supported WMs is just metacity and kwin. However, we're
trying to make our best in supporting other window managers, and icewm
is a kind of "nice to have support for".
In AWT code, we have some tweaks related to particular WMs like
metacity, kwin and compiz. For other WMs, we just detect if they support
_NET protocol, because the basic ICCCM is obviously not enough.
If xmonad and stumpwm are not _NET compliant, it's not a surprise we
don't handle them perfectly.
> A hint which I didn't mention earlier to try to avoid confusion: In
> stumpwm I can actually make keyboard input work by confusing the heck
> out of *something*, by doing this:
> * Start a virtual desktop with two frames.
> * Start a terminal (for example) in one frame, and the Swing
> application (e.g. Notepad) in the other.
> * At this point keyboard input is broken.
> * I hit my stumpwm keyboard combination to switch focus to the *other*
> (non-Swing) Window in the other frame.
> * I then click the Swing application with my *mouse*.
> * I can now enter text in the Swing application ***BUT*** stumpwm is
> still convinced that keyboard focus is in the other frame.
Right now, I can't say for sure where is the problem. It requires more
investigation. It can be a problem with how these WMs handle input focus
model, if they send WM_TAKE_FOCUS or not (we heavily rely on this in
AWT), and even with how they decorate our windows (reparenting).
> I don't know whether that behavior is a stumpwm bug, Java bug, or
> something else, but perhaps it may help shed light on what's happening
> for someone with more knowledge of the inner workings than me.
You can file a bug against AWT, and we'll most likely accept it, however
it will be of very low priority - see above. So I'd recommend you to
contact the window manager maintaners first.
> I tested to make sure this triggers with an absolutely trivial and
> minimalistic JFrame-with-a-JTextField application:
More information about the awt-dev