Red Hat Bugzilla – Bug 124421
xterm cursor block sometimes left in bad state
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
The xterm cursor block is supposed to be filled when the window is in
focus, and empty (outlined) when the window is not in focus. Under
circumstances I've not been able to ascertain exactly, but which occur
to me annoyingly often, the cursor block is left filled (as if window
was focused) when the focus is changed to another window. It seems
this happens mostly, possibly exclusively, when changing focus to
another window using the mouse rather than alt-tab.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start a couple of xterms.
2. Flick focus back and forth with alt-tab.
3. Then try to change focus with the mouse. This _might_ reproduce it.
I realize this is of low priority, and I will flag it as such, since
most people don't use xterm under FC2, but I hope there is a fix,
since it will cause me to break things in my room in rage. The
problem is most often: I operate xmms with the mouse, and, thinking
the focus is still on my xterm since the cursor block is filled,
happly type away into my xmms. Nasal demons ensue.
I've seen an occasional/rare report for this, but don't have a
case I've been able to reproduce.
It shouldn't be too hard to reproduce, since it happens so often to
me. Try having at least 3 programs open, flip focus back and forth
with alt-tab between xterm and another program. Stop such that the
xterm is focused. Now click on the third window with your mouse.
This seems to do it for me every time. At least here and now. :)
I'm unable to reproduce this problem. I started up 2 xterms, xchat,
evolution, and xmms all in windowed mode, and set the sizes of the
windows so they all fit onscreen without overlap. I ran some
commands in the xterm windows, then once the prompt returned, I tried
various different methods of switching between apps using ALT-TAB and
using the mouse. In every single case, when xterm lost focus, the
cursor changed to a hollow box cursor.
I'm going to close this as "WORKSFORME" for now, as I'm unable to
reproduce with the information provided above. If you can provide
a 100% reproduceable test case with detailed step by step instructions
however, please feel free to reopen this report and include details
and we will reinvestigate the issue.
Thanks in advance.
Sorry, but I'm reopening this. :-)
To be absolutely sure it's reproducible, I added a virgin test user to
my system and reproduced it. It's subtle, but not hard. I apologize
for not kludging my way to a more precise way to reproduce earlier.
1. Start two xterms.
2. Position mouse cursor over one of them.
3. Use alt-tab to flick focus back and forth a few times.
4. End flicking with focus on the xterm that has mouse cursor above.
5. Move mouse cursor to other xterm and click.
Here's a screenshot for the unbelievers:
I may add that this is nothing new in FC2, it was in FC1, RH9 and
possibly earlier. Possibly forever. I've also reproduced it with
other window managers.
Following the steps outlined in comment #4, I am now able to
reproduce this problem 100% on Fedora Core 1, using xterm 179.
At step 5 above, both xterms have a solid block cursor, whereas
one of them should be hollowed out.
Thanks for providing a reliable test case for reproduceability,
as that is generally required in order for a developer to be
able to investigate a given issue.
I was able to reproduce this 1-2 times (but not last weekend with
patch #193). I'll revisit this to see if it's obscured by the
fixes in #192, etc.
Bumping to FC3 -- still a problem.
This problem is fixed in xterm 194 and later I believe. There
was a couple very similar bugs around bugzilla that seem to indicate
that at least. I've put xterm-200 in rawhide currently, which
should resolve this.
Please test xterm-200 from rawhide, and let us know if that
resolves the problem or not.
Thanks in advance.
Closing bug as fixed in "RAWHIDE". File a new bug report or reopen this
one if you prefer, if the problem comes back.
Sorry about the late response, my monitor crapped out so I've been without this
desktop for a while.
I don't see any change in 200. I installed it and followed my instructions
above and that still reproduced it. Reopening.
I'll just add a few anecdotes here. I was unable to reproduce this under KDE,
it is clear that there's something in the way the wm signals focus changes that
creates this problem. However, I noticed other, related problems under KDE.
For example, after running mplayer, the focus would be on the xterm again, but
the cursor block would then _not_ be filled.
I also somehow managed to create two filled cursor blocks on my Indy running
IRIX 6.5 and 4Dwm and some version of rxvt (which AFAIK is derived from an xterm
codebase). All this suggests that there's something downright wrong with the
code that decides when to fill the damn thing and not. :) Thanks for looking
Actually rxvt does not use any code from xterm.
(But since they use many of the same low-level X calls,
it could be due to the same problem).
I've managed to get 100% reproduction using icewm, FC4, and xterm v8.6.2 using
the following method:
* Open up Firefox
* Open up xterm
* Put focus on Firefox, and hover your mouse over the xterm
* Use alt-tab
* Use it again
Hey presto, a filled cursor whatever you choose to do with your xterm.
There was some additional information in gentoo's #100728
where I could reproduce something like this. I added one
of the suggested workarounds for this in #204 (the simpler
one that doesn't simply remove the whole chunk of code ;-).
I've reproduced the problem on FC-4 with xterm-200 by following
the instructions in Comment #13, but using the KDE wm and with
xterm and mozilla windows.
Using xterm-205 compiled on FC-4 seemed to fix the problem.
xterm-205-1 is now submitted to Rawhide, and will be submitted to FC-4 updates
testing and FC-4 updates shortly.
Closing as 'RAWHIDE' for now.
From User-Agent: XML-RPC
xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.