scrollbar drag doesn't extend to side




20 years ago
18 years ago


(Reporter: brad, Assigned: eric)


Windows NT

Firefox Tracking Flags

(Not tracked)




20 years ago
In Windows, standard behavior is for the scrollbar drag to work above the
scrollbar element as well as to equal widths to the left and right
(for vertical, above and below for horizontal) of the
scrollbar. Currently, if you are dragging the scrollbar and slide the cursor
off of the scrollbar (without lifting the mouse button), the bar snaps back
to its original position. This should only happen if you slide the cursor
more than one full scrollbar-width to the side.


20 years ago
Assignee: shuang → don


20 years ago
Assignee: don → karnaze
Component: UE/UI → Widget Set


20 years ago
Assignee: karnaze → evaughan

Comment 1

20 years ago
I'm not sure whether to assign this to Eric or Kevin.


20 years ago
Target Milestone: M9

Comment 2

20 years ago
I don't think it is worth fixing in the current implementation, let's just leave
it with Eric as a reminder for the new scrollbar widget to get it right.  BTW,
correct behavior does not necessarily mean whatever Windows apps do (Windows UI
guidelines just say "the distance...before the scroll box snaps back is
proportional to the width of the scroll bar"). For example, Linux has no
boundary on this, and I for greatly prefer this since I don't always drag a
strict horizontal or vertical line. cc german for UE input.

Comment 3

20 years ago
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired

Comment 4

20 years ago
A common behaviour for recent programs (ie: IE 5.0) using the scrollbars is the
capture the mouse entirely and allow the user to control the scrollbar using
vertical position only.  Snapping the scrollbar back tends to be aggrivating and
serves no useful purpose, AFAIK.


20 years ago
Target Milestone: M9 → M10

Comment 5

20 years ago
GFX scrollbar landing is will be early m10


20 years ago
Target Milestone: M10 → M12

Comment 6

19 years ago
mass-moving all m12 bugs to m13


19 years ago
Target Milestone: M13 → M20

Comment 7

19 years ago
Setting priority


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 8

19 years ago
GFX scrollbars match IE 5.0 behavior => fixed.

Comment 9

19 years ago
I know this is marked as RESOLVED FIXED, but I couldn't find another place to
enter this comment.  I followed the thread in the newsgroups about this behavior
a while back, and I agree that the snapping-back of the scrollbars one the mouse
moves a certain distance away from the scrollbar is pretty wacky.  But I use it,
especially with long documents.  If I want to scroll down to look at another
reference to something, when I'm done I just move my mouse over to the left far
enough and I return to my previous position in the huge document.

This is one thing that's extremely painful about IE now.  And remembering where
the thumb of the scrollbar is isn't always an option, because with the resizable
scrollbar thumb, it's sometimes so small that being 1/4 inch off means a couple
of pages.

So how about letting me cancel the dragging of the thumb by pressing Esc?  Then,
for most people, it will work exactly the same as it does now, but if someone
wants to cancel the scroll they can (I think at least a bit intuitively) press
the Esc key.

I'm off to look at the code to see where this would fit in.  Not being one that
has looked at the code too much, I probably won't come back with anything.  But
at least I'm trying...

Comment 10

19 years ago
Adding myself to the CC: list, in case anyone responds to my comments.

Comment 11

19 years ago
I said I would look for a place where the Esc key would go, and I did.  Then I
got lost.  This is probably why I haven't been able to contribute any coding
solutions.  But, just as a guess, would it go into nsSliderFrame::HandleEvent?

Comment 12

19 years ago
Verifying on:
  Windows 98 build 2000-09-19-05-M18
  Linux RedHat6.2 build 2000-09-19-08-M18
You need to log in before you can comment on or make changes to this bug.