Bug 98806 - Emacs scrollbar behavior change under X in Red Hat 9.0 with GNOME
Summary: Emacs scrollbar behavior change under X in Red Hat 9.0 with GNOME
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-07-08 23:20 UTC by wdc
Modified: 2007-04-18 16:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-01-15 02:01:16 UTC
Embargoed:


Attachments (Terms of Use)

Description wdc 2003-07-08 23:20:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030613

Description of problem:
We just went to Red Hat 9.0, and I noticed that the behavior of scrollbars changed.

The old (and documented within emacs) behavior is:

Left mouse click: scroll the line next to the scroll bar mouse position to the top
of the window.

Right mouse click: scroll the top line down to the location of the scroll bar
mouse click.

The new behavior is:

Right mouse click: ignored.

Left moust click: scroll up if mouse is above the elevator, scroll down if the
mouse is below the elevator.

I suspect this properly is a bug report for version 7.0 of libXaw3d, but I'm not
sure if that's really the source.

Further complicating reproducibility: Apparently people who do not run gnome do
not experience this problem.

I am REALLY disheartened that somehow Emacs would end up becoming infected by
the bad Microsoft-style scrollbar behavior.  Ideally, I'd be able to tell ALL my
scrollbars to behave the way the Emacs scrollbars USED to.  CMU got this right
in 1986, but apparently the value of this style has been lost, (along with the
fine art of keeping buttons that kill things FAR AWAY from buttons that are
commonly pressed.)

Does anyone else see this?
Does anyone know how to fix this?

-wdc


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


How reproducible:
Always

Steps to Reproduce:
1.Start emacs under X
2.Read in a file bigger than a screen full.
3.See how the scroll bar ignores right mouse button, and no longer behaves
properly with the left mouse button.
    

Additional info:

Comment 1 Jens Petersen 2003-07-09 05:50:08 UTC
When I run emacs in GNOME, the right mouse button isn't ignored for me
(it acts just like the left button though).

Which version of Red Hat Linux did you upgrade from btw?  

Comment 2 wdc 2003-07-09 14:36:06 UTC
As I think of it, I may have been careless, and not clicked the right mouse button out of the
elevator.

We updated in an orderly progression from 7.3 to 8.0 to 9.0.

I think you ARE seeing the same behavior as I am seeing if your buttons do not do the "move line 
to here" behavior.

-wdc

Comment 3 wdc 2003-07-11 19:38:10 UTC
Now that I have the relevant system in front of me I confirm that the original
description of right mouse behavior was incorrect.  You and I ARE seeing the
same behavior.  The revised right mouse button behavior is:

Right mouse click: Same as Left mouse click.

I hope you can find the source of this problem and produce a rememdy.
Emacs was the last, most important place, for me to have acceptable scrollbar
behavior.  Losing it is a real shock.


Comment 4 Jens Petersen 2003-07-26 07:54:32 UTC
Hmmm, maybe you want the "--without-toolkit-scroll-bars" build configure option?

Comment 5 Jens Petersen 2004-01-15 02:01:16 UTC
While I sympathize, I don't want to change the default scrollbar
now used by Emacs.  If you really want this changed, then I suggest
you take this up with the Emacs Developers (eg on the emacs-devel
mailing-list).  However you may like to know that the next version of 
Emacs should support the Gtk toolkit, and also seems to behave in
the same way as Xaw3d scrollbars, except Button-3 is ignored
afaict).

[Btw I'm surprised by the dependence of the behaviour the desktop
environment.]




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