90985 - dragging thumb away from scrollbar shouldn't cancel scrolling on unix

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Christopher Blizzard (:blizzard)]

See bug #22175 for the cause of this bug.  Someone want to whip up a patch?

Comment 1

[tor]

*** Bug 90982 has been marked as a duplicate of this bug. ***

Comment 2

[R.K.Aa.]

The summary here makes it look like scrolling gets cancelled "for good", which
is wrong. During grab, viewport snaps back and forth between initial grab-view
and scrolled-to view, when you slide cursor out/into the 100 px zone. This
provides a "snap-scroll" feature i found to increase usability. Makes it easyer
to compare pieces of text at different locataions in a page. Did anyone actually
TRY this feature, or is this bug just a pp reflex?

Why not suggest to GTK, KDE and MOTIF crew to adjust accordingly instead? It
would be an improvement. I'm usually reluctant picking up on new interface
features, but this one I learned to appreciate in approx. one minute. Which
means it's very good.

I'd like to hear compelling reasons as to why NOT keep the scroll as it is
today. What enhanced usability does the "never let go" approach offer?

<beg> Whatever the outcome of this bug, at least make it a pref!.. </beg>

Comment 3

[Morten Welinder]

> I'd like to hear compelling reasons as to why NOT keep the scroll as it is
> today.

It's a feature and features are generally good.  But this feature has a bad
tendency of triggering when I don't want it to.   And the result of doing so
is highly confusing: you lose your reading spot.

The features assumes that you scroll quite precisely.  I find that I do not,
especially not with a cluttered (physical) desktop.  Previously in mozilla as
well as in all other programs that come to mind, that did not matter.  The
point is that you are scrolling with your eyes on the text, not on the scroll
bar.

Multiply the required distance by 3-4 and I don't think I would have a problem.
Otherwise, a pref would be great.

Comment 4

[Jason Tibbitts]

With this change, usability of the browser has gone through the floor for me. 
If I move the mouse and grab the scroller, either the mouse should be restrained
in its horizontal motion or (preferrably, and te way it used to be) horizontal
motion should not make a difference to the scrollbar position.

When I'm scrolling and reading, I do not watch the pointer closely to make sure
it doesn't drift too far from the scrollbar.  After all, I'm reading the text,
not watching the pointer.

Yes, the current behavior is how windows does it.  That doesn't make it a good
behavior; this is one of the reasons why I find windows incredibly difficult to
use.  Please don't make this behavior permanent without making it configurable.

And multiplying the distince (unless you do it by a hundredfold or something) is
not sufficient; it should not matter where on the screen my mouse wanders, as
long as I have the scroller held, the screen should scroll with the mouse.

Comment 5

[Marcin Orlowski]

In AmigaOS you could press RMB while dragging (no matter: icons, scrollbars
whatever) to cancel the operation. What about planting that in mozilla? Seeings
ieas of using i.e. ESC to cancel mouse actions it seems clear to me not many of
mozilla users/developers have ever seen other OSes than windoze and macos in
action ;)

Comment 6

[Tim Powell]

Based on the negative comments (and I'll add my dislike for this "bug fix" on 
Win2K) from non-unix users, I'd think the snap-back should be a pref. Or expose 
the horzontal scrolling distance before it snaps back as a pref. I'd set mine to 
really big, maybe even the screen width. :-) This bug should also be set to 
platform/OS All/All.

Comment 7

[tor]

Attachment: add slider.snapmultiplier pref, default to zero on unix (disable)

Comment 8

[tor]

Attachment: switch to slider.snapMultiplier for consistency

Comment 9

[:deanis74]

Looks fairly straight-forward.  Thanks, tor, for doing work to resolve a problem
instead of complaining about it.  r=[e-mail]

Marcin: There are many bugs filed on ways to cancel scrolling and dragging.  See
bug 70279, which is the tracking bug.

tpowell: Fixing bug 22175 added platform parity on Windows and Mac.  This bug is
for Linux only.

Comment 10

[tor]

assignee -> tor.

Comment 11

[Blake Ross]

Looks okay. I like how you combined a pref to change the snap size with a pref
to turn it off. sr=blake

Comment 12

[tor]

Checked in.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Aren't all prefs supposed to have a default value in all.js that's then
overriden by the platform-specific files if needed?

I know we have a fallback value in c++, but there are good reasons for having
all prefs be in all.js -- it facilitates getting a list of all prefs, for
example...

Just thinking that we may want to add 

pref("slider.snapMultiplier", 6);

to all.js

Comment 14

[Blake Ross]

Yep, this is supposed to have an entry in all.js.

Comment 15

[:deanis74]

I blame myself.

Comment 16

[tor]

all.js default checked in.

Comment 17

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 18

[Aaron Peterson]

This behavior is broken again in Firefox 19...


It doesn't even snap back when I leave the scroll area.


It should snap back, and then if I go back into the scroll area, it should go right back to where I was moving to.

So it allows for a graceful cancel of a scroll, 

Right now, my scrolls are never ever canceled.
I lose my spot all the time when scrolling.

If I want to go back to where I was, I CAN'T

I can't think of another solution for this problem.  I don't see anything in the about:config to change to bring this behavior back.

I am on Kubuntu 12.04

Comment 19

[Aaron Peterson]

Sorry,  I had changed the setting mentioned earlier above, and it required a browser restart to take effect.

Now I will be using firefox instead of Chrome, because I can snap back and forth and gracefully cancel a scroll!

(It should be on by default in unix, but at least it is configurable after 15 minutes of searching online)