103981 - scrollbar thumb is too small, so clicking scrollbar twice sometimes returns to initial position

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Niels Aufbau]

Steps to reproduce:
1. Find a long page (at least 3 or 4 screenfulls).
2. Scroll to the top or middle of the page.
3. Click just below the scrollbar thumb.
4. Mousedown again, without moving your cursor.

Actual result: after step 3, the scrollbar thumb is 2 or 3 pixels below the
cursor, so at step 4 you're scrolled back up.

Expected result: I should now be able to drag the thumb by moving the mouse.  In
Internet Explorer and Netscape 4, I would now be several pixels *inside* the
thumb,  so even if I included "move up a pixel or two" between steps 3 and 4, IE
and NS4 would still do the right thing.

I run into this bug often while surfing porn.  I think the reason is that I
scroll more quickly when I look at porn than I do while I read text.  It may
also  be because I'm more distracted by what's in the content area :)

I'm using build 2001100803 on Windows 98.

Comment 1

[Martin Poirier]

It took me about 2 minutes to see what you mean, but yes I see this on win98SE
moz trunk build 2001100903. This even happens on this page, so look no further
for a testcase ;).

Comment 2

[Alex Vincent [:WeirdAl]]

INVALID.

Reason:  Clicking on the scrollbar outside the thumb is equivalent to a
pagedown.  On this page (at 1024x768, anyway), the "Create a new attachment"
link is at the bottom of the viewable window when you're scrolled to the top. 
But, when you do this page down, the "Create a new attachment" link is just
above the visible portion (in fact, the bottom edge of the mini-table which
contains it is visible).

Add this to your testcase:

5.  Click on any whitespace in the page, and press the up key.

On this page, the scrollbar thumb will move up to where your mouse pointer is
over it.  Simultaneously, the "Create a new attachment" link reappears at the
top of the screen.

Result:  the behavior described is exactly what should happen.  This is not a
bug in the browser.  Marking RESOLVED INVALID.

Comment 3

[Alex Vincent [:WeirdAl]]

I oughta cc myself on any bug I dare to mark INVALID.  Sorry for the spam.

Comment 4

[Niels Aufbau]

The top and bottom of the scrollbar thumb aren't meant to give you an exact
indication of where you're scrolled to on a page.  If they were, the scrollbar
thumb's size would fluctuate as you scrolled, and on long pages the scrollbar
thumb would be one pixel tall.

In other Windows 98 apps, a double-click (fast or slow) below the thumb never
scrolls down and up again, even if I move the cursor a pixel or two during the
double-click.  It either scrolls down two pages, or it scrolls down one page and
then lets me grab it without moving my cursor.  In addition to making scrolling
less confusing, this guarentees that I can put the cursor somewhere near the
thumb, click a few times, and end up in a state where I can drag the scrollbar
thumbs.

Do scrollbars behave differently on other operating systems?

By the way, on Windows 98, a pagedown using the scrollbar keeps one line
visible, and a pagedown using the keyboard keeps two lines visible.

Comment 5

[Alex Vincent [:WeirdAl]]

At first, I'm inclined to say "You're wrong" and invalidate the bug again, but
that would just lead to this bug becoming a flamewar.  :)  I take reopening a
bug for confirmation after being marked invalid seriously, and I trust you do as
well.

However, I find on further examination in the latest nightly that 1 pagedown !=
1 click on the scrollbar for this page, in terms of pixels shifted down.  The
thumb does appear to land in a position proportionate to where the page ends up,
so we know that much isn't broken.

This leads me to believe that you and I are both at least partially right.  On
IE6, a pagedown is equal to a click just below the thumb (the page lands in
exactly the same spot in both scenarios).

I would suggest the bug is really about the distance the scrollbar click goes
down as opposed to what a pagedown key will generate.  Using the standard down
arrow versus the down arrow key produces a matching scroll distance.

Comment 6

[Alex Vincent [:WeirdAl]]

Looking for related bugs which this may be a dup of.  :)

bug 11751 looks similar to what I'm reading this situation of.  Not going to
mark it dup, though, without a second opinion. 

Comment 7

[Niels Aufbau]

Let me try to describe the bug in another way.  If you place the cursor just
below the scrollbar thumb and click several times, the thumb jumps back and
forth between two positions, skipping several pixels (including the pixel where
your cursor is).  In other Windows apps, there are always 2-4 pixels of overlap
between the scrollbar's old position and its new position, so it's impossible
for the scrollbar to jump back and forth like that.  This difference exists
despite the fact that both Notepad and Mozilla leave exactly one line of
(normal-sized) text visible after you click above or below the scrollbar thumb.

Fixing bug 11751 (making it so clicking below the thumb leaves 2-3 lines
visible, like pgdn, instead of one) would fix the "double-click can scroll back"
problem for large browser windows, which is what annoys me the most, but:
a) it would not fix the double-click problem for textareas, which must leave
exactly one line visible.
b) it would not fix the double-click problem at low window sizes (try it
yourself, using the pgdn key at step 3).
c) it would not fix the strangeness that two scroll positions can overlap by one
line of visible text while the corresponding positions of the scrollbar thumb
have a several-pixel gap between them.

I have the ability to confirm bugs now, but I take disagreement seriously and
would like a second opinion :)

Comment 8

[Peter Trudelle]

->future, if not invalid.

Comment 9

[John Morrison]

*** Bug 129003 has been marked as a duplicate of this bug. ***

Comment 10

[Tuukka Tolvanen (sp3000)]

I see this on linux, os->all. Clicking on scrollbar through under the thumb bit
correctly scrolls down <= 1 screenful. The through area below the thumb
indicates a position on page below the current view, so after scrolling <= 1
screenful down it cannot correspond to a spot on page above the scrolled view.

Comment 11

[Jerry Baker]

An animated gif of the behavior will probably make this a lot more clear for 
everybody. It took me a few minutes to see what the reporter was saying.

Comment 12

[Jerry Baker]

Attachment: Mozilla's behavior

Shows the behavior reporter describes

Comment 13

[Jerry Baker]

Try doing that in another app (what the attachment shows) ;-)

Adding self to CC:

Comment 14

[Jerry Baker]

Mass removing self from CC list.

Comment 15

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.

Comment 16

[David Hyatt]

--> default owner

Comment 17

[m_mozilla]

Can we change the summary to
    proportional scrollbar thumb is too small for long page/list (need min size)
or
    proportional scrollbar thumb needs minimum size (too small for long content)

The "double-clicking sometimes..." seems not to be the bug. I'm seeing this bug
in the URL bar's dropdown. Example:

    slashdot.org

gives me a *huge* autocomplete list, and I don't see *any* scrollbar thumb in
that list. If I type

    slashdot.org/article

then my thumb is visible (about five pixels tall) because the list is shorter.
If I type

    slashdot.org/article.pl?sid=02/08

then my proportional thumb is about half the height of the scrollbar 'elevator
shaft'.

The problem is that proportional scrollbar thumbs need to have a minimum size
(and do in non-mozilla apps). I'm going to update the summary. If folks decide I
should not have, the original was:

    scrollbar thumb is too small,
    so double-clicking scrollbar sometimes returns to initial position

I'm on mac os x trunk build 2002091603

-matt

Comment 18

[Lewis Jardine]

Please file a new bug - this bug is for the issue that the scrollbar thumb is
_always_ a few pixels too small, so multiple clicks on the non-thumb area don't
'summon' the tab to under the mouse, but cause it to 'bounce'. Have a look at
attachment 78527 [details] to see an animated .gif of this behaviour. None of the symptoms
you describe seem relevent to this bug.

Comment 19

[m_mozilla]

ok, new bug created

    http://bugzilla.mozilla.org/show_bug.cgi?id=169413

resetting summary on this bug. Sorry for the confusion.

I confess that I now that I understand what this bug is meant to be, I don't see
it as a bug. The screenshot didn't seem to show a 'too small' scroll thumb. It
seemed to show an appropriate min-sized thumb. IMO, the double-click was doing
exactly what I would expect it to do. If one wants to double-click and not see
that behavior, one shouldn't double-click so close to the scroll thumb. Instead,
put your pointer less than one thumb's height from the top of the scroll bar and
double-click there. That will ensure "page-up * 2" behavior.

removing my cc here. If anyone is interested in the scroll thumbs that actually
get single-pixel-sized, see bug 169413

-matt

Comment 20

[Lewis Jardine]

This is a valid bug, simply because scrollbars in other applications (windows
native widgets, for instance) don't do this, and therefore it is confusing to
the user when it happens. We're not talking about a massively too small thumb;
it's only one pixel too small on each side.

Comment 21

[Wayne Mery (:wsmwk)]

WFM current trunk builds
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3