xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run any Java application (use JDK1.6u1 or higher and xmonad with
SetWMName extension to overcome the gray rectangle bug). E.g. run Notepad
demo from demo/jfc/Stylepad directory in JDK home, like so:
java -jar $JDK_LOCATION/demo/jfc/Stylepad/Stylepad.jar
2. After starting the window doesn't get focus (that's a first example of
the problem) 
3. click inside the window, so it gets focus. If it is a Stylepad
application, you'd be able to enter text in the editor window
4. Switch to another  window on the same workspace, either using keys, or mouse
5. Switch back
6. Although the frame around the Java app becomes highlighted (meaning
xmonad thinks it has the focus), Java app doesn't seem to get the focus
(you cannot edit the text or open menus in Stylepad until you click with
your mouse into the window)

What is the expected output? What do you see instead?
Java application should get the focus after switching back to its window
from another window.

What version of the product are you using? On what operating system?
xmonad 0.7 + latest patches from the repository
Debian GNU/Linux, 2.6.24-3

Please provide any additional information below.

I've done an investigation together with Java AWT engineers and we've found
that this is a problem in xmonad, not in Java. The problem is that xmonad
ignores the WM_TAKE_FOCUS protocol which is described in the ICCCM (see
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7).

Java sets <Globally Active> model for its Frames/Dialogs, and <No Input>
model for its Windows. In both of these cases the WM shouldn't call
XSetInputFocus by itself. In the former case it should send the
WM_TAKE_FOCUS event to the window (when it decides that the toplevel window
should get the focus), in the latter case it shouldn't do anything (Java
processes all the clicks by itself).

See also the attached C file. You can compile it using the following command:
gcc -o native -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 native.c

When run, this file file prints the FocusIn/FocusOut events and also it
prints WM_TAKE_FOCUS events if they are sent. The correct behaviour of this
program in the WM is to print the message "event on frame %i:
WM_TAKE_FOCUS" (where %i is the number of frame, 0 or 1 in this program)
whenever the focus is set to its window using the WM (either using keys, or
mouse). Incorrect behaviour is when it prints only pairs of the
"FocusIn"/"FocusOut" messages.

I tried reproducing the same problem in IceWM and found that it handles the
WM_TAKE_FOCUS protocol correctly (both on this test program and on real
applications).

I attempted to fix the problem myself but for some reason the fix didn't
work. See the attached Operations.hs file which contains the fix attempt
starting with the line

    -------- WM_TAKE_FOCUS fix attempt starts here --------

If you have any questions or need any further clarification from the Java
AWT engineers, please contact me at Ivan.Tarasov@gmail.com.

I consider this problem as "quite serious" (on some abstract seriousness
scale), because it ruins the xmonad using experience as well as Java
application using experience when they are used together.

Original issue reported on code.google.com by Ivan.Tar...@gmail.com on 13 Apr 2008 at 4:10

Attachments:

• native.c
• Operations.hs

[GoogleCodeExporter]

Please attach a patch in 'darcs send' format, this makes it much easier for us 
to see
what has been changed.

Original comment by SpencerJ...@gmail.com on 14 Apr 2008 at 9:14

[GoogleCodeExporter]

failed fix attempt patch is in the attachment

Original comment by Ivan.Tar...@gmail.com on 14 Apr 2008 at 12:45

Attachments:

• issue177.darcs-patch

[GoogleCodeExporter]

Potentially the same thing using claws-mail auto complete, and workspace 
switching.

1. Compose new mail, and attempt to auto complete an email address
2. Once the completion list pops up, use mod-<n> to switch to a different work 
space
3. The completion dialog stays raised, and only disappears when clicked on.

Original comment by awesomel...@gmail.com on 17 Apr 2008 at 9:32

[GoogleCodeExporter]

Ivan's patch works for me (tested with Stylepad). Can anybody else test and 
confirm?

Original comment by peigoovi@gmail.com on 23 Nov 2008 at 9:05

• Changed state: Fixed

[GoogleCodeExporter]

Don’t call it fixed until it was added to the repository, otherwise the patch 
might
get lost.

Original comment by nome...@gmail.com on 23 Nov 2008 at 10:55

[GoogleCodeExporter]

I can confirm that it fixes my problems with focus in some Java apps. I didn't 
try
this patch before, because author said it doesn't work and already installed 
fluxbox
to work with those apps. :)

Original comment by asts...@gmail.com on 24 Nov 2008 at 5:13

[GoogleCodeExporter]

Ivan's patch works without modification on my setup: 
 - xmonad 0.8
 - jdk 1.6.0_02
 - matlab r2008b
 - ubuntu 8.04

Thanks a heap; it's been incredibly painful for me having to focus with the 
mouse

Original comment by pauld.mccarthy on 19 Mar 2009 at 1:34

[GoogleCodeExporter]

I have had focus-related issues in netbeans 6.5 and other java applications 
(xmonad
0.8.1 configuration attached, Ubuntu 8.10, java-6-sun-1.6.0.10, slightly 
different
issues in 32 and 64-bit versions of Ubuntu), e.g. no keyboard focus until you 
click
in a window. This problem meant that I found netbeans unusable under xmonad.

Applying this patch to the current darcs version of xmonad seems to have solved 
the
problem for me, at least in netbeans!

Original comment by kri...@gmail.com on 19 Mar 2009 at 9:45

Attachments:

• xmonad.hs

[GoogleCodeExporter]

Another success story: matlab 7.8.0.347 (2009a) on xmonad 0.8.1.

Original comment by beneficial.terminator@gmail.com on 31 Mar 2009 at 7:03

[GoogleCodeExporter]

This works as a logHook too. No need to patch xmonad

      logHook            = takeTopFocus >> setWMName "LG3D", -- fix java Bug

-- Send WM_TAKE_FOCUS
takeTopFocus = withWindowSet $ maybe (setFocusX =<< asks theRoot) takeFocusX . 
W.peek

atom_WM_TAKE_FOCUS      = getAtom "WM_TAKE_FOCUS"
takeFocusX w = withWindowSet $ \ws -> do
    dpy <- asks display
    wmtakef <- atom_WM_TAKE_FOCUS
    wmprot <- atom_WM_PROTOCOLS

    protocols <- io $ getWMProtocols dpy w
    when (wmtakef `elem` protocols) $ do
        io $ allocaXEvent $ \ev -> do
            setEventType ev clientMessage
            setClientMessageEvent ev w wmprot 32 wmtakef currentTime
            sendEvent dpy w False noEventMask ev

Original comment by nils.dec...@gmail.com on 11 Jun 2009 at 9:48

[GoogleCodeExporter]

Here's my take at a better patch that I believe correctly implements each of the
focus models specified by ICCCM. The main difference to the previous patch 
posted
here is that setInputFocus is not called when the input hint is not set. I get 
better
results on netbeans that I did with the previous patch.

Original comment by gere...@gmail.com on 22 Jun 2009 at 5:24

Attachments:

• takefocus.darcs-patch

[GoogleCodeExporter]

Ivan's patch worked for me too.
I've tested with JDeveloper on jdk 1.6.0_14

Original comment by hgabreu on 26 Jun 2009 at 2:01

[GoogleCodeExporter]

Why is this not accepted over a year later?  This defect renders Netbeans, for
example, rather unusuable under XMonad, especially if you want to use the jVi 
plugin
with it.

This should have high priority to get into the next release.

Original comment by f.luit...@gmail.com on 1 Oct 2009 at 8:23

[GoogleCodeExporter]

We've actually only had a patch that isn't labeled as a "failed attempt" for a 
few
months, which is one reason this hasn't seen action yet.  The second reason is 
that I
don't typically use Java applications, and therefore don't notice the bug.

I'll try to get to this.  However, it would certainly help if a few people 
could test
gereedy's patch and also make sure that it applies cleanly against xmonad head.

Original comment by SpencerJ...@gmail.com on 2 Oct 2009 at 3:20

[GoogleCodeExporter]

I've just tried gereedy's patch against latest darcs.  This works fine for java
(1.6.0_16) but breaks xev: All keyboard events to the focused xev window go to 
the
previously focused window instead.

Original comment by simon.si...@gmail.com on 2 Oct 2009 at 11:36

[GoogleCodeExporter]

I can confirm Simon's observation.  The regression observed with xev is ugly -- 
still
I prefer a working Netbeans and jEdit over a working xev at this moment...

Maybe somebody with a working knowledge of the X protocol (not me) could have a
closer look.  I have a hunch we're not far away from a clean patch.

In any case, Xmonad not cooperating with Java Swing applications should be a 
no-no.

Original comment by f.luit...@gmail.com on 3 Oct 2009 at 12:45

[GoogleCodeExporter]

The xev problem was because I didn't handle the case where the input hint field 
of
WMHints wasn't set properly. This updated patchset takes care of that problem.

Original comment by gere...@gmail.com on 10 Oct 2009 at 11:21

Attachments:

• takefocus2.darcs-patch

[GoogleCodeExporter]

The second patch by gereedy works fine here on latest darcs xmonad: no problems 
with
the java stuff and xev works fine again.

Original comment by simon.si...@gmail.com on 21 Oct 2009 at 7:32

[GoogleCodeExporter]

Second patch works for me too: no keyboard problems with java applications any 
more.
Not sure what the problem was with xev, nor how to validate that it is fixed.

Original comment by insta...@gmail.com on 21 Oct 2009 at 8:50

[GoogleCodeExporter]

This patch also fixes Cellwriter (a handwriting recognition / virtual keyboard 
input
panel, often used on tablet PCs running linux) under xmonad.

Without this patch, the only way to get Cellwriter to send its input somewhere 
useful
is to doIgnore it in a manageHook. But that is a work-around at best, because it
means normal xmonad keybindings won't work any more in Cellwriter.

Original comment by toby.cub...@gmail.com on 22 Oct 2009 at 5:03

[GoogleCodeExporter]

I've tested last patch too and it worked great. Solved java and xev issues!
In my option this is a severe issue and there's no reason for not being in next 
release.

Original comment by hgabreu on 23 Oct 2009 at 12:49

[GoogleCodeExporter]

This patch causes keyboard input in openoffice writer to go to the main window 
even
when you have the bullets and numbering formatting window open. This is useful, 
then
those buttons cannot be modified with the keyboard. Perhaps compliance to
WM_TAKE_FOCUS should be configurable.

xev works properly.

I'm not sure of the java focus issues: with some apps like jmemorize, you have 
to
occasionally click in a grouping of widgets to gain keyboard focus. On the other
hand, once the app has keyboard focus in the right area, the keyboard focus 
remains
after focusing other windows and workspaces using xmonad.

Original comment by vogt.a...@gmail.com on 23 Oct 2009 at 2:05

• Added labels: Component-Core, Usability

[GoogleCodeExporter]

Just to clarify the openoffice issue as described by Adam Vogt:

When a floating toolbar in openoffice gets focus all keyboard input is send to 
the
previously focused window.

A quick search on the openoffice issue tracker brought up
http://www.openoffice.org/issues/show_bug.cgi?id=96395 which seems to suggest 
that
the toolbar should not get focus in the first place.

Original comment by simon.si...@gmail.com on 23 Oct 2009 at 8:43

[GoogleCodeExporter]

Geoff Reedy's last patch doesn't apply cleanly against latest darcs (due to the
merging of extensible state stuff). Attached is a patch bundle including the 
old ones
that probably works as the old one did.

Original comment by vogt.a...@gmail.com on 27 Nov 2009 at 3:07

Attachments:

• track-currently-processing-event.dpatch

[GoogleCodeExporter]

Latest patch works perfectly in xmonad-darcs, fixing my Cellwriter issues. 
Thank you so much for updating it!

Original comment by s...@archlinux.us on 30 Nov 2009 at 4:33

[GoogleCodeExporter]

Original comment by SpencerJ...@gmail.com on 8 Dec 2009 at 5:18

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

A similar problem with ion window manager was reported to Java:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798064

Original comment by n142...@gmail.com on 15 Dec 2009 at 10:21

[GoogleCodeExporter]

Perhaps one should only keep track of the last event time because the 
currentEvent is
only used for getting the time? When the incoming event is non-timed just leave 
the
lastEventTime untouched.

Original comment by ari.m.sa...@gmail.com on 28 Jan 2010 at 8:09

[GoogleCodeExporter]

The latest patch from vogt.adam also makes the onboard[1] application work 
correctly.
Also see the discussion in [2].

[1] https://wiki.ubuntu.com/Accessibility/Projects/onBoard
[2] http://www.haskell.org/pipermail/xmonad/2010-February/009703.html

Original comment by v.dijk....@gmail.com on 3 Feb 2010 at 9:57

[GoogleCodeExporter]

The latest patch solves the problems with focus in Matlab for me. Good work!

Original comment by k.ljungk...@gmail.com on 13 Feb 2010 at 9:34

[GoogleCodeExporter]

Just wanted to add that usage of Maple (another commercial Java app) benefits 
from
the latest patch, too. (It doesn't apply right away to the current repository, 
but
the conflict resolution is obvious.)

Original comment by malte.so...@gmail.com on 15 Feb 2010 at 12:43

[GoogleCodeExporter]

patch cannot be applied in latest darcs
Sorry, but why this patch have not been applied to the repo yet?

Original comment by hgabreu on 22 Feb 2010 at 2:28

[GoogleCodeExporter]

Here you go:

Original comment by vogt.a...@gmail.com on 22 Feb 2010 at 2:54

Attachments:

• track-currently-processing-event.dpatch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Any progress on this subject? I'm currently using patched darcs xmonad, but it 
makes
working with openoffice really hard. Is this ever going to be fixed for real?

Original comment by donvo...@gmail.com on 12 Apr 2010 at 6:45

[GoogleCodeExporter]

You should probably patch your OpenOffice as well.

I recall reading something about focus of their toolbars being problematic and 
some
discussion of proposed changes.

Original comment by hramr...@gmail.com on 12 Apr 2010 at 8:58

[GoogleCodeExporter]

fixes netbeans for me

Original comment by twentyaf...@gmail.com on 21 May 2010 at 8:07

[GoogleCodeExporter]

Yes, this patch seems to solve problems for a lot of people. Why has it still 
not
made it into the repository?

Original comment by k.ljungk...@gmail.com on 21 May 2010 at 9:02

[GoogleCodeExporter]

Because OpenOffice is broken in such a way that it works worse with the patch 
applied.

Original comment by hramr...@gmail.com on 21 May 2010 at 9:19

[GoogleCodeExporter]

I believe this patch has a bug that is only visible after several hours of 
having a
java application opened and working with it (e.g. netbeans), read on please.

Sometimes when running java under *patched* xmonad, after working for a while (3
hours or so) with a java application (say, netbeans) I find other applications
(especially firefox) to be very slow at gaining focus, e.g. if I switch from 
the java
workspace to the firefox one, it'll take about a second or so to give focus to 
the
firefox instance. If I close the java application then everything gets back to
normal. It gets worst as time goes by, until the java application is closed.

Has anyone experienced a similar behavior? What can I do to troubleshoot this? 
if I
run "top" I see X taking a lot of cpu when changing between WS. Any help will be
appreciated.

Original comment by donvo...@gmail.com on 21 May 2010 at 9:25

[GoogleCodeExporter]

I've experienced the same behaviour with non-Java apps and without that patch, 
so it
might not be related to that patch (for me it's typically emacs + firefox).

Original comment by ivan.miljenovic@gmail.com on 21 May 2010 at 9:31

[GoogleCodeExporter]

This patch (by vogt.adam, comment 33) solved the issues I had with Java 
applications. 
As I do a lot of development with Java, I'd really like to see this patch 
included in 
the repository. Without the patch some Java applications are almost unusable.

Original comment by ralf.kis...@gmail.com on 25 May 2010 at 10:29

[GoogleCodeExporter]

I tried patch from vogt.adam but it isn't working. I am using mucommander, 
which is
written in java and when I for example do copy I cannot control copy dialog from
keyword. Even if I click on dialog with mouse I can't use keyboard - I have to 
click
with mouse to some form control (button, text field, etc) - then keyboard is 
working. 

Original comment by j.kra...@gmail.com on 29 May 2010 at 10:46

[GoogleCodeExporter]

I noticed that this patch also fixes another issue with Matlab. When using GUI
functions like inputdlg, without the patch the dialog doesn't seem to get focus 
at
all, whereas after applying the patch it works as expected.

Original comment by k.ljungk...@gmail.com on 2 Jun 2010 at 9:46

[GoogleCodeExporter]

patch by by vogt.adam, comment 33 works very well

Original comment by elijah.e...@gmail.com on 12 Sep 2010 at 1:36

[GoogleCodeExporter]

Patch in comment 33 works for me too, applied against the latest darcs, fixing 
Cellwriter perfectly!

Original comment by s...@archlinux.us on 15 Sep 2010 at 7:00

[GoogleCodeExporter]

Will this patch ever make it into the repository / and or prebuild packages? I 
find it very cumbersome to patch xmonad using Ubuntu. On Gentoo it's not a 
problem, but Ubuntu took a lot of fiddling around for me...

Original comment by pentaso...@gmail.com on 16 Sep 2010 at 9:13

[GoogleCodeExporter]

Sorry for any ignorance revealed by this comment but...  Not used to darcs or 
haskell.  However, I applied the patch from Comment 33 with
darcs apply <patchname>.dpatch
Then ran Setup with configure/build/install
Then restarted xmonad (and later did a full reboot just to be sure).
I still have the following behavior in netbeans / jvi
click in editor
hit : (bring up seperate command subwindow that gets focus)
hit escape or enter (closing command window)
cursor is gone, only way back to editor is by cilcking inside it, which of 
course renders netbeans / jvi unusable...

A) Is this the problem the patch was supposed to solve?
and
B) If so, any ideas as to why it is not solved?

Original comment by ml.nwgr...@gmail.com on 7 Oct 2010 at 2:27

[GoogleCodeExporter]

I also find this patch, or any solution for java apps ignoring 
focus-follows-mouse, indispensable.

Original comment by ques...@gmail.com on 26 Jan 2011 at 9:18

[GoogleCodeExporter]

Just so everyone is aware, Tony Morris, has packaged this up and it has been 
committed to XMonadContrib. 

It can be found in XMonad.Hooks.ICCCMFocus.

Original comment by mthibb...@gmail.com on 26 Jan 2011 at 9:39