Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Right mouse button should scroll oppositely on scrollbar buttons

NEW
Unassigned

Status

()

Core
XUL
--
enhancement
16 years ago
7 months ago

People

(Reporter: beanladen, Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
The right mouse button currently has no function in
the scrollbar. As for most other (Unix) applications,
this button should just scroll back, like the left
button scrolls forward.
(Reporter)

Comment 1

16 years ago
I forgot to mention that scrolling for both
the left and right button should take place always,
regardless of whether the mouse is on the slider
or not. The middle mouse button suffices to grab
the slider. This behaviour would be in conformance
to most newer Unix applications.

Comment 2

16 years ago
Um... the only applications that exhibit the behavior you describe are the ones
using Athena widgets -- a widget set that is almost 15 years old, ugly, and
unintuitive to use.

None of the modern (gnome/kde) applications on my machine that I have tried
exhibit the behavior you describe -- they all treat right-clicks and left-clicks
the same in the scrollbar.
(Reporter)

Comment 3

16 years ago
I'm not using kde/gnome, as I don't like CDE (partly 
because they don't have those nice functions). Xterm 
and Emacs, which are the two applications which almost 
everyone uses, have this behaviour. By the way, it's not 
the fact that it is a new or old behaviour that makes it 
so appealing -- it's just because it's SIMPLE, PRACTICAL, 
INTUTITIVE and TIME SAVING because you simply can scroll 
very fast without moving the mouse ! So I do not see any 
reason to let the right mouse being nonfunctional in the 
scrollbar, and it's more intuitive to let the left and 
right mouse work this way regardless of the slider position.
I cannot imagine any reason not to do it like this, 
because it's simply the best way to do it !

Comment 4

16 years ago
You can't tell me it's intuitive for anyone to see the browser scroll down when
he clicked with the left mouse button above the slider. Everyone expects the
browser to scroll up, not to screw up.
Neither It would be intuitive if this behaviour got implemented for the right
button only.

In the meantime mouse wheels were developed, they allow scrolling without moving
the mouse. Along with scrolling via up/down-buttons I think there are enough
alternative ways.
Resolving as Wontfix. Feel free to reopen the bug if you disagree.

Thank you for testing Mozilla.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 5

16 years ago
Hmm, seems that not everyone is thinking
the same way. A good solution would be either
to make the behaviour configurable, or, even
better, to adapt it to the UI the user is
currently running (means: AsIs on KDE/gnome,
as proposed on naked XFree/Fvwm/tvm/mwm, Windows-like
on Windows x.x, Bee-like on BeOs, etc.), so he always 
gets a consistent interface to his environment.
Ideally, such elements should be managed by the
window manager currently running.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---

Comment 6

16 years ago
1)  there is no way to get the window manager to handle the scrollbar

2)  If the window manager is changed while Mozilla is running, then what?

3)  How _does_ one tell whether one is running gnome/kde as opposed to just
    running their respective default window managers?

4)  This is a UI design issue, so over to UI design feedback.

See also bug 30497 for some background.
Assignee: trudelle → mpt
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets → User Interface Design
Ever confirmed: true
QA Contact: jrgm → zach

Comment 7

16 years ago
I had to use Athena scrollbars in my xterms for three years (1997-1999), and 
look how I turned out. That should be warning enough to anybody not to try and 
implement imitations of them. The Athena widget set deserves to be shot, 
beaten, stoned, incinerated, hanged, drawn, and quartered. And then killed.

However.

For those poor souls on non-Macintosh OSen, who do not have the Smart Scrolling 
pref to put up and down scrollbar buttons next to each other -- and even if 
Smart Scrolling was implemented as a `System'-category pref on those other OSen 
-- it *would* save users a large amount of time if they could switch between 
scrolling down and scrolling up without moving the mouse at all. (That's why 
some mice have scroll wheels, after all.)

Add to that the fact that users are unlikely to try right-clicking on a 
scrollbar button to do anything else, and you have a cool and froody idea:

    On a scrollbar button, the left mouse button should scroll in the
    direction indicated by the button, and the right mouse button should
    scroll in the opposite direction.

Resummarizing, --> XP Toolkit/Widgets.
Assignee: mpt → hyatt
Component: User Interface Design → XP Toolkit/Widgets
OS: Linux → All
QA Contact: zach → jrgm
Hardware: PC → All
Summary: right mouse button should scroll back → Right mouse button should scroll oppositely on scrollbar buttons

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1

Comment 8

16 years ago
Also see bug 38466 and bug 38467 about context menus for scrollbars.

Comment 9

15 years ago
I agree with Matthew Thomas, and I think that many users coming from the RISC OS
world would agree too (since this is a standard feature under RISC OS). The left
mouse button should scroll in the indicated direction (i.e. what we already
have) and the right mouse button should scroll in the opposite direction. And
this should work on both the arrow buttons (slow scrolling) and in the scroll
bar itself (to scroll one page).

Comment 10

15 years ago
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Target Milestone: mozilla1.1alpha → ---

Updated

15 years ago
Target Milestone: --- → Future
Assignee: jag → nobody
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.