Bug 89449 - cursor ghost in xterm when changing fonts
Summary: cursor ghost in xterm when changing fonts
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-22 23:08 UTC by Nickolai Zeldovich
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-25 08:53:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of xterm's failure (2.22 KB, image/gif)
2003-04-23 22:53 UTC, Nickolai Zeldovich
no flags Details

Description Nickolai Zeldovich 2003-04-22 23:08:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Description of problem:
When the font in xterm is changed (from the "VT Fonts"
menu, which comes up when Control+M3 is pressed), under
some conditions a ghost of the old cursor remains visible.


Version-Release number of selected component (if applicable):
XFree86-4.2.0-8

How reproducible:
Always

Steps to Reproduce:
1.Use a window manager with focus following the pointer
2.Run "xterm -fn 10x20"
3.Press Control+M3 in the xterm and select the "Small" font, but
  in such a way that the mouse cursor will end up outside xterm
  after the font change is completed.
4.Observe a ghost of the old, 10x20 font cursor appear in the
  xterm.

Actual Results:  A ghost of the old, previous font cursor appears in the xterm.

Expected Results:  There should be no ghost of the old cursor in the previous font.

Additional info:

Comment 1 Mike A. Harris 2003-04-23 07:01:00 UTC
Attach a screenshot, and your X server log and config file as file
attachments please.

Thanks.

Comment 2 Nickolai Zeldovich 2003-04-23 22:53:59 UTC
Created attachment 91263 [details]
Screenshot of xterm's failure

The attached screenshot demonstrates this bug.
Observe the shell prompt and current cursor (solid block)
in the new, small font, and an outline of the old, large
font, cursor right around where the new cursor is now.

Comment 3 Mike A. Harris 2003-04-25 08:46:54 UTC
> Control+M3

What is M3?  In 3 years of maintaining XFree86, and about 8 years of using
it, I've never heard of a key labeled or refered to as M3.

We do not officially support xterm, but merely provide it for end user
convenience.  You're recommended to use one of our supported terminal
applications - konsole and gnome-terminal

If you believe it to be an xterm bug, please file a bug report upstream
in XFree86 bugzilla at:  http://bugs.xfree86.org

You're recommended to upgrade to Red Hat Linux 9 first with XFree86 4.3.0,
as if this is a real bug in xterm, the upstream maintainer will want you
to be using the latest version of XFree86 likely first.



Comment 4 Mike A. Harris 2003-04-25 08:53:25 UTC
Actually, I just decoded the secret message of M3 being the third mouse
button.  Interesting confusion.

I now see the menu you are talking about (which I never knew existed before).

I just tried to reproduce this problem on Red Hat Linux 9, and also on
Red Hat Linux 8.0, and 7.1.  I'm unable to reproduce this on any of the
three.

Either way, if the problem occurs for you in Red Hat Linux 9, it's something
the xterm maintainer upstream will have to handle.  Please report it there
if the problem persists.


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