Open
Bug 97858
Opened 23 years ago
Updated 2 years ago
Right mouse button should scroll oppositely on scrollbar buttons
Categories
(Core :: XUL, enhancement)
Core
XUL
Tracking
()
NEW
Future
People
(Reporter: beanladen, Unassigned)
Details
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.
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•23 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.
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•23 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
Closed: 23 years ago
Resolution: --- → WONTFIX
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•23 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•23 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•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
Comment 9•22 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•22 years ago
|
||
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Target Milestone: mozilla1.1alpha → ---
Updated•22 years ago
|
Target Milestone: --- → Future
Updated•16 years ago
|
Assignee: jag → nobody
Updated•13 years ago
|
QA Contact: jrgmorrison → xptoolkit.widgets
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•