User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 If you scroll to a middle of the page (so the scroll bar is half way down) and click and hold the scroll bar, the page will immediately jump up. When you pull the scroll bar down (still holding the mouse) it will jump back to where it was originally and start scrolling smoothly. Reproducible: Always Steps to Reproduce: 1. 2. 3.

Confirming. In order to be able to see the bug, you have to choose "Click in the scrollbar to: Scroll to here" in the OS X appearance prefs panel. Firefox 2 doesn't have this bug => regression.

- // On Mac the option key inverts the scroll-to-here preference. - PRBool invertScrollToClick = PR_FALSE; - mouseEvent->GetAltKey(&invertScrollToClick); Why are we getting rid of this?

Because that's only true when the mouse is over the scrollbar track. When clicking the thumb, on Mac OS X the scrollbar shouldn't scroll to click, regardless of preference and pressed keys. nsSliderFrame::MouseDown only handles clicks on the thumb. Clicks in the scrollbar track area are handled by nsSliderFrame::HandleEvent.

Comment on attachment 316626 [details] [diff] [review] Fix v1.0: fix jumping bug, disable scroll-to-click on the thumb on Mac OS X, fix mouse button handling, add scrollbar tests Requesting approval1.9: Simple fix for an annoying glitch, very low risk, tests included.

Comment on attachment 316626 [details] [diff] [review] Fix v1.0: fix jumping bug, disable scroll-to-click on the thumb on Mac OS X, fix mouse button handling, add scrollbar tests a1.9=beltzner

Markus, you don't have CVS access, right? (Do you want it?)

Wow. That would be cool.

I didn't check this in because the test added by this patch fails for me, on Mac, when run in the iframe from the main test runner (e.g. runtests.py --test-path=toolkit/content/ --autorun). Running it directly passes.

Huh. Thanks for checking, I'll see what I can do.

In the iframe the scrollbar had a different size, so the scrollbar thumb was smaller and the synthesized click didn't hit it. Now the scrollbar is always 500px wide.

OK... my patch breaks the test for the scale control. I'll have a look at that tomorrow.

Never mind. The scale test fails for me without the patch, too.

With the latest patch, 4 "On platforms other than Mac OS X, holding shift should enable scroll-to-click on the scrollbar thumb." tests are failing for me, on Windows.

Thank you, Gavin. I think I've found the bug in the test (the mouse button wasn't checked), could you test again?

Thanks Markus, the test now passes on Windows and Mac for me. I'll check this in later today.

mozilla/layout/xul/base/src/nsSliderFrame.cpp 1.181 mozilla/toolkit/content/tests/widgets/Makefile.in 1.57 mozilla/toolkit/content/tests/widgets/test_scrollbar.xul 1.1

Could this have caused bug 430723?

2 of the tests are failing here, because I use 'fat' scrollbars (10px wider than normal). This patch fixes the failures for me, it's a bit of a kludge, because I don't really understand how the test works. I wonder where the value of 160 for x is coming from.

(In reply to comment #21) > I wonder where the value of 160 for x is coming from. Pretty much guesswork; I needed a point that was between the center and the right edge of the scrollbar thumb and 160 did the job. - Not good enough, as it turns out. I'm fine with your patch; using the scrollbar height as a hint for the variation of the thumb size sounds like a good idea.