31490 - Scrollbar: click-dragging within elevator produces weird results

Status: VERIFIED DUPLICATE of bug 71458

(Core :: XUL, defect, P4)

Description

[Jesse Ruderman]

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.

Comment 1

[Peter Trudelle]

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.

Comment 2

[Jesse Ruderman]

My native scrollbars don't ignore the drag. What program are you comparing 
mozilla against?

Comment 3

[Peter Trudelle]

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.

Comment 4

[Sean Richardson]

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 [e-mail] says, Mozilla is providing the same behaviour for 
click-drag as a click-hold with no drag gets. 

Comment 5

[Peter Trudelle]

reassigning to evaughan as p4 for m18

Comment 6

[Sean Richardson]

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.

[e-mail], is anything like this the case on MacOS?

Comment 7

[Adam Masri]

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

Comment 8

[Peter Trudelle]

Mass moving M18 bugs to M19

Comment 9

[Peter Trudelle]

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

Comment 10

[John Morrison]

(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future'
milestone

Comment 11

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 71458 ***

Comment 12

[:deanis74]

verifying dupe of the larger-number bug, since it has some analysis in it