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.

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

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.

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

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.

GFX scrollbar landing is will be early m10

mass-moving all m12 bugs to m13

Setting priority

GFX scrollbars match IE 5.0 behavior => fixed.

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...

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

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?

Verifying on: Windows 98 build 2000-09-19-05-M18 Linux RedHat6.2 build 2000-09-19-08-M18