scrolling doesn't resume after moving cursor after scrollbar slider hits cursor

RESOLVED DUPLICATE of bug 153946

Status

()

Core
XUL
RESOLVED DUPLICATE of bug 153946
14 years ago
11 years ago

People

(Reporter: Daniel B., Assigned: jag (Peter Annema))

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827

If you click and hold below a scrollbar slider/thumb/elevator until the slider 
hits (or passes) the mouse cursor and stops, then if you slide the mouse cursor 
further down, paging (scrolling by panefuls) does not resume.

This behavior is unnecessarily inconvenient for the user:

If scrolling resumed, the user could continue paging down by simply dragging 
the mouse further down.

With the current behavior, to continue once, the user has to:
  - release the mouse button
  - make sure the mouse cursor is still in the scrollbar
  - press the mouse button again

To resume continue additional times, the user has to repeat the above steps
multiple times, instead of simply dragging down a bit, stopping, and dragging
some more.


I can't check right now what some Linux program and UI toolkits to, but
Windows (XP) scrollbars resume paging down if you move the mouse cursor after
the slider hits the mouse cursor.



Related bug reports:

- bug 71458 is very similar, but deals with dragging before the slider reaches 
  the original mouse click position.

- bug 64866 wants paging not to stop at the mouse cursor in the first place

- bug 64866 comment 22 agrees with this bug report:

    In all scrollbars i've seen besides mozilla that _do_ stop at the 
    cursor position, they continue paging if you subsequently move the 
    mouse further along the scrollbar in the direction in which you are 
    scrolling.  Mozilla fails to do so.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

14 years ago
Actually, this is the same behavior I was talking about in bug 71458.

*** This bug has been marked as a duplicate of 153946 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 2

11 years ago
(In reply to comment #1)
> *** This bug has been marked as a duplicate of 153946 ***

It can't be.  That bug is marked fixed, but the problem still exists
on Linux *with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 SeaMonkey/1.0.6))/
You need to log in before you can comment on or make changes to this bug.