Bug 53925 - keyboard focus in scrollbar loses input
Summary: keyboard focus in scrollbar loses input
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-21 18:49 UTC by Andrew Isaacson
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-28 11:17:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Andrew Isaacson 2001-09-21 18:49:10 UTC
Using the default RedHat setup, start an XTerm with the Scrollbar visible.
For example, "xterm -sb".  Now give the xterm focus, and note that your
typing is echoed.  Now, place the mouse pointer in the scrollbar and note
that your typing is not echoed.

To Fix:  Edit the file /usr/X11R6/lib/X11/app-defaults/XTerm.  Towards
the end of this file, change the line
*VT100*translations:    #override \
*VT100.translations:    #override \
(note the change from asterisk to period.)  Start up a new XTerm, and note
that typing in the scrollbar is now correctly echoed.

The particular problem is due to a misdesign in X11, characterized by jwz
in the Xscreensaver code: (xscreensaver.c:77)

 *   The reason that we can't select KeyPresses on windows that don't have
 *   them already is that, when dispatching a KeyPress event, X finds the
 *   lowest (leafmost) window in the hierarchy on which *any* client
 *   for KeyPress, and sends the event to that window.

So, if the #override applies to everything below VT100 in the window
hierarchy (which is what happens with the current RedHat setup, which uses
VT100*translations) then the keypresses are delivered to the scrollbar
widget, and do not arrive at the VT100 widget.  Whereas if the #override
applies just to the VT100 widget (which is what the change I propose causes
to happen) then keypresses are delivered and interpreted correctly.

Comment 1 Mike A. Harris 2001-09-25 07:21:05 UTC
Problem confirmed in RHL 7.0, 7.1.  Proposed solution
confirmed to fix this behaviour also.  Investigating
if there are any potential negative side effects of
making the change.  If not, I'll add it to a future

Comment 2 Mike A. Harris 2002-01-25 09:08:51 UTC
I'm not sure what ramifications this sort of change would have.  Past
changes to xterm resources have been grave mistakes because they have
fixed the problem reported by one user at the expense of breaking
something else for another user.

Also, we provide, but do not officially support xterm.  Our supported
terminals are konsole, and gnome-terminal.  Although I wont make this
change at this time, I am defering your request for future consideration.

Comment 3 Andrew Isaacson 2002-01-26 01:10:29 UTC
If RedHat does not support xterm, then you should ship the vendor version.  The
configuration file you ship is NOT the version that's shipped with XFree86, and
your changes BREAK the application.  If you don't understand the resource syntax
well enough to understand whether this bugfix will have other undesirable
effects, perhaps you should forward the change to someone who does understand.

Thomas Dickey (xterm maintainer) said
> Regarding your analysis - that's how I read the code as well.  But in
> either case, making changes to app-defaults files should be done sparingly
> to avoid breaking things that the user has already setup: once you have
> set a pattern, the user can't set that pattern.

The code in question IS a change to the app-default file, and the breakage is in
the code that RedHat adds.  If you can't fix bugs in the things YOU are adding
to standard UNIX utilities, what kind of distribution are you?

Comment 4 Mike A. Harris 2002-01-28 11:17:02 UTC
>The code in question IS a change to the app-default file, and the breakage is in
>the code that RedHat adds.  If you can't fix bugs in the things YOU are adding
>to standard UNIX utilities, what kind of distribution are you?

We're evidently the kind of distribution that draws rude obnoxious
users who feel the need to insult us.  For a second there, I thought
I was reading slashdot commentary and not bugzilla.  It is bug reports
like this one, that make me want to close all requests for enhancement
on things like xterm and other similar stuff.  We make these changes
at our users requests usually - to show that we are open to our users
needs and suggestions.

It is not EVER possible to fully realize all of the implications a
particular change may induce, especially if one is not intimately
familiar with a proposed change.  As such, if a given change is
 made, and makes it through the plethora of our own testing, plus
the all of our public beta testing, without any bug reports
streaming in - we can only conclude that a given change is functional.

And for the record, I had absolutely nothing to do with any of these
changes to xterm which have broke whatever they have broke for whoever
they've broke them for.  Nonetheless, I am the one who ends up now
being negatively attacked.  I don't know a heck of a lot about xterm
at all, and am hesitant to make changes to it, in particular due
to receiving negative bug reports like this one.

I've nonetheless made the change of * to . in my current package, which
will appear in rawhide.  Aside from fixing "bugs that those idiots at
Red Hat have stupidly inflicted on xterm users", I don't plan on ever
making any future enhancements to xterm.  It's much more productive
for me to pass bug reports upstream and let them sort it out, and spend
my time on areas of XFree86 that I am personally much more familiar
with, and actually care about.

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