[xmonad] Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol

[codesite-noreply at google.com]

Issue 177: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

New issue report by Ivan.Tarasov:
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 at 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.



Attachments:
	native.c  2.5 KB
	Operations.hs  22.1 KB


Issue attributes:
	Status: New
	Owner: ----
	Labels: Type-Defect Priority-Medium

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings