Open Bug 64866 Opened 24 years ago Updated 2 years ago

Linux: click-and-hold in scrollbar elevator should not stop at cursor position

Categories

(Core :: XUL, defect)

x86
Linux
defect

Tracking

()

Future

People

(Reporter: spam, Unassigned)

References

Details

2001010908 linux SEA

Been seeing this forever, haven't found a bug on it:

When i click scrollbar area above or below slider in 4.75, and then keep
mousebutton pressed in, the slider will slide till it reaches top or bottom of
page.

If i move the mouse during this (still pressing button) - it doesn't change
anything - slider still slides till it reaches top (or bottom) - or till i
release mousebutton.


The behaviour in mozilla is quite different:
The slider will only slide till it hits the point i pressed at on scrollbar.
And if i move the mouse while button is pressed, the scrolling completely stops.

I much prefer the behaviour in NC4.75 in this respect, as it is way easyer to
maneuvre with. Smoother, fewer clicks, less jerky.
typo
Summary: browser scrollbar not behaving line in 4.* → browser scrollbar not behaving like in 4.*
I'm sorry you don't like it, but it is behaving as designed.  ->invalid.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Tsk tsk. Reopening and filing as RFE.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I would like to add that not only is this feature-request 4xp, and in other
words in line with how NC4.* behaves on Linux: It is in also how every Gnome and
KDE application with scrollbars behave.
Well, we aren't really a Gnome app or a KDE app, and we certainly aren't  a
Motif app, so we aren't bound by their behavior. I wish there were platform
guidelines for the UI, as there are on Mac and Windows, but AFAIK there aren't.
Personally, I think this is a defect in their toolkits; most GUI environments
work the way our scrollbars do.  I find it very strange to have the mousedown in
the pageUp area, yet have the window paging down, as eventually happens with the
behavior you want.  We actually had this behavior in an early implementation,
but it was considered a defect, and we got a lot of strong negative feedback
about it. In any case, we will probably move such behavior into JS in the
future, so it can be skinnable, and someone can write a Gnome-ish or Motif-like
theme, or whatever other look/feel they prefer. ->evaughan/future
Assignee: trudelle → evaughan
Status: REOPENED → NEW
Target Milestone: --- → Future
changing summary. Being the same as 4.x is not the issue. Being the same as
other apps is.
Personally I much prefer the mozilla way, but I am a windows user.
Summary: browser scrollbar not behaving like in 4.* → [RFE] Browser scrollbar on linux should behave like Gnome/KDE/Motif scrollbars
If memory serves me right, this is also to some extent normal behaviour in
Windows applications: Once you've grabbed the slider and still hold button
pressed in, the window is still responsive to the drag if you zig-zag your way a
little - outside left/right visible scrollbar. It doesnt "drop" the drag as soon
as you are outside visible border. Which, in my opinion, is a user-friendly
behaviour - we are organic beeings, and some have problems dragging the slider
in a perfectly straight line downwards etc.
This bug has nothing to do with dragging the thumb, it is about whether holding
mouseDown in the pgUp/pgDn area of the scrollbar will continue to cause
scrolling in the same direction, even when the thumb moves to the other side of
the cursor. New summary is thus much too broad. Current behavior matches Windows
(98 at least) and Mac.
Sorry.. I should take a break. But compare it: The behaviour is inconsistent:
The slider button behaves correct - responding as long as grab is held.
It would be logical that the rest of the scrollbar area behaved in the same way.
rkaa, is this a dup of bug 31490?
Not an exact match.. Linux behaviour differs in that it keeps scrolling.
You can page-scroll a whole page with one click and no movement on Linux.
In bug 71458 comment 1, Trudelle thinks that is plain wrong - but I like it -
it's a practical feature.
Blocks: 78248
Changing summary from
[RFE] Browser scrollbar on linux should behave like Gnome/KDE/Motif scrollbars
to
Linux: click-and-hold in scrollbar elevator should not stop at cursor position

Does this really depend on bug 78248?  Click-and-hold works on Windows and
Linux, it's just that it shouldn't stop as soon on Linux in order to be
consistent with other Linux scrollbars.
Summary: [RFE] Browser scrollbar on linux should behave like Gnome/KDE/Motif scrollbars → Linux: click-and-hold in scrollbar elevator should not stop at cursor position
Anyone check what the Gnome UI Guidelines (for Gnome 2.0) are saying about this?
If there is currently nothing to determine if a mouse-button is pressed.. that -
IMO - seems to be a requirement for a fix of this bug.
see comment http://bugzilla.mozilla.org/show_bug.cgi?id=71458#c2 where bug 79248
is also a dependency
typo: bug 71458 depends on bug 78248
wrt comment 13, I didn't see anything relevant to this in a quick skim of the
GNOME 2.0 Human Interface Guidelines (CVS draft)
http://developer.gnome.org/projects/gup/hig/ ... but then, why would there be,
as there's the common toolkit in that context. The gtk+ 1 and 2 bits I have work
as described in this bug, i.e. holding mouse button down in the scrollbar
through scrolls pages so the scrollbar thumb goes all the way and past the mouse
pointer location.
Depends on: 26828
This bug needs attention as it affects basic functionality.  

It does not depend on bug 26828 [Platform-specific look+feel for <scrollbar>] as
suggested in the summary above.  That one has to do with /appearance/ of the
scrollbar, this one has to do with the function of the slider in respect to both
primary pointer button state and pointer location.

I fail to see the reason why it would block bug 78248 [[RFE] API to determine if
a mouse button is pressed] either, but that's neither here nor there.

bug 71458 [Scrollbars don't adjust to new mouse position while in a page scroll]
was referenced at one point in these comments, but that one should in no way
pertain to Unix(Linux) implementations using the GTK stuff, since the slider
should already be motoring towards the end of the scrollbar toward which it was
started, while the primary pointer button remains pressed, regardless the
pointer's current position.


There are actually two bugs being represented by this present(ly inactive?) bug:

Primary: the slider does not continue past the point in the trough from where
it's motion was initiated with the primary pointer button, as it should within
the framework of the GTK.

Secondary: the slider ceases motion for this activity if/when the pointer (with
yet held primary button) leaves the trough.

I hope those descriptions are succinct enough.

In the GTK+ 2.0 Tutorial, Chapter 8, "Range Widgets", (currently available at
http://www.gtk.org/tutorial/ch-rangewidgets.html) it's stated in the very first
paragraph:

"Dragging the slider with the pointer moves it back and forth within the trough,
while clicking in the trough advances the slider towards the location of the
click, either completely, or by a designated amount, depending on which mouse
button is used."

That information is unchanged from the tutorial for version 1.2 of the toolkit
(currently available at http://www.esc.auckland.ac.nz/Docs/gtk/gtk_tut.html).

The action of advancing the slider directly to the point in the trough where the
pointer resides while pressing the middle button (button 3?) has been correctly
implemented.  That corresponds directly to the "by a designated amount" above. 
The slider currently remains captive and active regardless the pointer location
in the entire screen so long as the button remains pressed.  It would appear
that in this matter, the middle pointer button works perfectly with the
scrollbar - don't change anything there.

The action of completely advancing the slider while the primary pointer button
is pressed has not been properly implemented using the current toolkit.  In the
context of the GTK, the primary button in the scrollbar trough does not
designate extent of slider travel, but simply direction.  The current
implementation has apparently been assigned the action specified in an entirely
different (foreign?) toolkit which does not natively put numerous pointing
device buttons to use.  In fact, the current implementation appears to have in
some way combined the two functions (distance and direction of travel) which are
clearly separated in the GTK, and relegated to different buttons.  If the
current implementation isn't found to be puzzling, see the paragraph previous to
this one and ask, regarding it, "why was this even done?".

If this bug needs to be broken into two separate items to get fixed, then that's
fine.  But it definitely needs attention.  Primarily, as respects the extent of
slider travel; and secondarily, as respects the cessation of same if/when the
pointer leaves the trough.

I searched through the past year's worth of messages in
netscape.public.mozilla.ui, which I deemed to be the appropriate forum, and
found nothing regarding this matter, so please be kind to me if I'm out of line
here.
IMO, the key phrase in the text you cite is "towards the location of the click".
 This bug asks for it to continue past this location, which would then be away
from, rather than toward the click.  I still think this is invalid, and the
toolkits you mention are defective.
I understand it to mean (both by the text and in conjunction with experience) to
mean that the slider *starts* moving in the direction of the click, and it
advances *completely* in the scrollbar.  Your current implementation on Unix is
broken.  It breaks the Unix toolkit you've chosen.

We have a working "come to this point" function.  We don't need our "scroll
completely in this direction" tool broken to incorporate the former by the
evident desire of someone (who doesn't use our tools?) to "fix" it for us based
upon their mis-{understanding,appreciation} of them.

The left mouse button action for Windows, and the only button action for the Mac
targets, have been "fixed".  Can't you see fit to do so in a way that doesn't
break ours in the process?  It's not as if the criteria were commonality across
systems (which would be a bad idea) since there's already divergent behavior,
both specified and realized.  

Please provide a way for the compilers to skip the breakage while producing
executables for us.

The current "severity" classification is incorrect but I don't have the
authority to alter it.  This is not a request for an enhancement, but rather a
very real (and aggravating) bug.

I have to wonder why, if you think the toolkits are defective, you opted to use
one of them.
This is the exact same issue as bug 71458, which is a valid bug for Windows. 
I'd prefer marking this as a dupe of that bug, since 71458 is much cleaner.
I don't think this is a dup of that bug, and the issue here is that correct
behavior may differ by platform.  I've appealed to the Gnome 2.0 folks directly
to help clarify this fine point. 
Severity: enhancement → minor
In all scrollbars i've seen besides mozilla that _do_ stop at the cursor
position, they continue paging if you subsequently move the mouse further along
the scrollbar in the direction in which you are scrolling. Mozilla fails to do so.
------- Additional Comment #22 From random832@rcbooks.org  2003-04-05 14:54 -------

> In all scrollbars i've seen besides mozilla that _do_ stop at the cursor
> position, they continue paging if you subsequently move the mouse further along
> the scrollbar in the direction in which you are scrolling. Mozilla fails to do so.

See new bug 224599 dealing with that specific aspect.

Keywords: 4xp

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: eric → nobody
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.