Scrollbar: click-dragging within elevator produces weird results

VERIFIED DUPLICATE of bug 71458

Status

()

P4
minor
VERIFIED DUPLICATE of bug 71458
19 years ago
17 years ago

People

(Reporter: jruderman, Assigned: eric)

Tracking

Trunk
Future
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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

19 years ago
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
(Reporter)

Comment 2

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

Comment 3

19 years ago
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 → ---

Comment 4

19 years ago
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 trudelle@netscape.com says, Mozilla is providing the same behaviour for 
click-drag as a click-hold with no drag gets. 
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

19 years ago
reassigning to evaughan as p4 for m18
Assignee: trudelle → evaughan
Priority: P3 → P4
Target Milestone: --- → M18

Comment 6

19 years ago
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.

masri@nolex.com, is anything like this the case on MacOS?

Comment 7

19 years ago
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

19 years ago
Mass moving M18 bugs to M19
Target Milestone: M18 → M19

Comment 9

19 years ago
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21

Comment 10

18 years ago
(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future'
milestone
Target Milestone: M21 → Future
(Reporter)

Comment 11

17 years ago

*** This bug has been marked as a duplicate of 71458 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 12

17 years ago
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.