Steps to reproduce: 1. Open a long document such as http://www.slashdot.org/ that has several screenfuls of vertical scrolling room. 2. Scroll to the top. 3. Click-hold right under the scrollbar thumb so that you scroll down about a screenful. 4. While still holding the mouse button, drag downward. Expected results: thumb continues moving as you scroll downward. (win32 only?) Actual results: thumb always stops where the mouse button was first pressed down.
Using today's NS verification build on Win98, I'm seeing exactly the same behavior as with native scrollbars: they ignore the drag. resolving as wfm.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
My native scrollbars don't ignore the drag. What program are you comparing mozilla against?
I was using Communicator 4.72, but thanks for objecting. I see the problem now, it is not the drag, the native scrollbars just see that you have the mousedown in the gray area, so they treat it like another click! This seems like a bug in native scrollbars to me, but that doesn't really matter if it is now standard behavior. We'll have to take into consideration what happens on other platforms before deciding what to do for GFX scrollbars. reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Confirmed. Tested with 2000-03-17-09-M15 on WinNT, the scrollbar slider stops moving down at the point in the elevator where the mousedown occured, even if the mouse pointer has moved further down from there by the time the slider moves down that far. This is with gfx-scrollbars enabled. The scrollbars of neither NN 4.72 nor explorer.exe stop at the mousedown location given the same click-drag downward gesture - in fact, so long as the left mouse button is down, the slider will move further down after stopping if the pointer is moved down further yet. No idea how this works on X or Mac. As firstname.lastname@example.org says, Mozilla is providing the same behaviour for click-drag as a click-hold with no drag gets.
Status: UNCONFIRMED → NEW
Ever confirmed: true
reassigning to evaughan as p4 for m18
Assignee: trudelle → evaughan
Priority: P3 → P4
Target Milestone: --- → M18
It seems likely that the fix for bug 26914, "Scrolling using gray area of scroll bar should move to pointer location", did not take into account the possibility of click-dragging... i.e., of the proper place to stop - the pointer location - possibly having moved from the mouse-down location by the time the slider gets there. On WinNT, click-dragging away from the slider in NN 4.x actually allows the drag to continue after the slider has "caught-up", one "page" at a time, so long as the pointer is not moved toward the original position of the slider, and the mouse button is not let up. This lets the user guess roughly how far the scrolling should move, and then, if it is not quite far enough, move it a bit further, all in one mousing action. That's a nice feature of the Native scrollbars, IMO. email@example.com, is anything like this the case on MacOS?
Nice call. Frankly, in all the years I've used GUIs, this particular gesture is one I've never used. But, indeed, bug 26914 does not take this into account. I just tried it in Communicator 4.72, as well as in the Finder of MacOS 9, and this gesture does indeed work in both those places. Therefore, I'd say this isn't a Windows only bug, but if this gesture is the same in Linux, then this is probably an all/all bug. - Adam
Mass moving M18 bugs to M19
Target Milestone: M18 → M19
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future' milestone
Target Milestone: M21 → Future
*** This bug has been marked as a duplicate of 71458 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 17 years ago
Resolution: --- → DUPLICATE
verifying dupe of the larger-number bug, since it has some analysis in it
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.