XTerm's cursor indicates whether the xterm has the keyboard focus. Usually, when it hasn't got the focus, the cursor is a hollow square, and when it has the focus, the cursor is a filled square (or the cursor might even blink, depending on your configuration). I found a bug that makes xterm permanently show the focused cursor. I can only reproduce this problem using fvwm as a window manager, however. Reproducible: Always Steps to Reproduce: 1. Open two xterms and place them so that they overlap 2. Resize the wholly visible xterm so that the overlapping area gets larger. (To do so, draw the corner of the window using the mouse. Use a corner that covers the second xterm.) Actual Results: Now the cursor of the covered xterm will look like it had got the keyboard focus. This will not change, no matter how often you give and take it the focus. The bug does not seem to depend on fvwm's configuration. You can reproduce it with an empty .fvwm directory. Another thing I've noticed: 1. Start a failsafe xterm session 2. Type 'xterm &' to produce a second xterm 3. Type 'fvwm &' 4. Trigger the bug as described above, using your two xterms 5. Exit fvwm You will notice that when fvwm exits, the xterm cursors will be bug-free again. I tried the combinations fvwm-2.5.10-r6 / xterm-196-r1 and fvwm-2.5.13-r1 / xterm-200-r3.
This looks like an xterm bug, it wont unset the screen->select INWINDOW flag while FOCUS is set, I dont know what the correct fix is but you can see commenting out the (screen->select & FOCUS) check in DoSpecialLeaveNotify() from misc.c fixes it. You can trigger it using the xse utility from within an xterm: $ xse -window $WINDOWID '<FocusOut> Normal DetailNone' '<EnterWindow> Normal DetailNone' '<FocusIn> Normal DetailNone' # Then fix it with: $ xse -window $WINDOWID '<FocusOut> Normal DetailNone' '<EnterWindow> Normal DetailNone' '<FocusIn> Normal DetailNone' As far as I can tell, there is nothing wrong with the sequence of events xterm receives, and either way it does not appear to be fvwm at fault, so back to you seemant :)
This sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=303889
fixed in xterm-205, in portage shortly
I've just emerged xterm-205, and the bug does still occur.
Thomas, any update about this?
no - I haven't made further changes in that area. (I can try to reproduce the problem - will check today).
A quick check shows I can reproduce the problem as described. So it's still on my to-do list.
Marking this upstream. Feel free to reopen once there's a patch available at least.
