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.
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 ;).
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
I oughta cc myself on any bug I dare to mark INVALID. Sorry for the spam.
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
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.
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.
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 :)
->future, if not invalid.
Target Milestone: --- → Future
*** Bug 129003 has been marked as a duplicate of this bug. ***
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.
OS: Windows 98 → All
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.
Try doing that in another app (what the attachment shows) ;-) Adding self to CC:
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
--> default owner
Assignee: hyatt → jaggernaut
Target Milestone: Future → ---
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
Summary: scrollbar thumb is too small, so double-clicking scrollbar sometimes returns to initial position → proportional scrollbar thumb needs minimum size (too small for long content)
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.
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
Summary: proportional scrollbar thumb needs minimum size (too small for long content) → scrollbar thumb is too small, so double-clicking scrollbar sometimes returns to initial position
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.
WFM current trunk builds Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 9 years ago
Resolution: --- → WORKSFORME
Summary: scrollbar thumb is too small, so double-clicking scrollbar sometimes returns to initial position → scrollbar thumb is too small, so clicking scrollbar twice sometimes returns to initial position
You need to log in before you can comment on or make changes to this bug.