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): xterm-179-6.EL How reproducible: Sometimes 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. Additional info: 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. Try this: 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: http://home.powertech.no/sletner/xterm-bug.png 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. Thanks.
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 into it!
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.