Bug 124421 - xterm cursor block sometimes left in bad state
xterm cursor block sometimes left in bad state
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
3
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-26 10:20 EDT by Stian Sletner
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-12 20:57:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stian Sletner 2004-05-26 10:20:27 EDT
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.
Comment 1 Thomas E. Dickey 2004-05-29 07:43:00 EDT
I've seen an occasional/rare report for this, but don't have a
case I've been able to reproduce.
Comment 2 Stian Sletner 2004-05-29 10:45:37 EDT
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. :)
Comment 3 Mike A. Harris 2004-06-18 18:27:42 EDT
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.
Comment 4 Stian Sletner 2004-06-26 14:54:41 EDT
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.
Comment 5 Mike A. Harris 2004-06-26 16:42:52 EDT
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.



Comment 6 Thomas E. Dickey 2004-07-24 10:42:02 EDT
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.
Comment 7 Stian Sletner 2004-12-02 06:38:21 EST
Bumping to FC3 -- still a problem.
Comment 8 Mike A. Harris 2005-02-08 19:51:40 EST
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.
Comment 9 Mike A. Harris 2005-04-16 12:23:08 EDT
Closing bug as fixed in "RAWHIDE".  File a new bug report or reopen this
one if you prefer, if the problem comes back.

Thanks.
Comment 10 Stian Sletner 2005-04-28 05:45:30 EDT
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.
Comment 11 Stian Sletner 2005-05-06 09:29:09 EDT
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!
Comment 12 Thomas E. Dickey 2005-05-06 09:44:51 EDT
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).
Comment 13 Clair Shaw 2005-09-07 14:51:39 EDT
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.
Comment 14 Thomas E. Dickey 2005-09-07 15:57:03 EDT
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 ;-).
Comment 15 Jason Vas Dias 2005-10-12 20:57:10 EDT
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.
Comment 16 Fedora Update System 2005-11-07 14:31:30 EST
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.
Comment 17 Fedora Update System 2005-11-14 13:02:01 EST
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.

Note You need to log in before you can comment on or make changes to this bug.