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

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@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
participants (1)
-
codesite-noreply@google.com