Build ID: 2000112204-Mtrunk Mac, recent Solaris build The performance of scrolling seems suboptimal when using the scrollbar arrows. Reproducible: Always Steps to reproduce: 1) Load a long page in another browser 2) Scroll down by keeping the scrollbar down button pressed 3) Load the same page in Mozilla 4) Scroll down by keeping the scrollbar down button pressed 5) Drag the scrollbar thumb up and down Actual results: Scrolling in Mozilla feels slower than scrolling in other browsers. However, when dragging the scrollbar thumb, it turns out that Mozilla is able to update the screen faster than when scrolling with the arrows. Expected results: Since Mozilla is able to do faster scrolling when dragging the scrollbar thumb, it would be nice is the scrolling speed with scrollbar arrows was closer to that performance.

This is one aspect of bug 56683, which was really in need of a separate bug for this point. This is primarily a user perception issue, as Henri's point about dragging the thumb makes clear. A rough check of the increment for different browsers (a small selection, but I can check Mac/Linux later), shows that while mozilla moves down ~1.0 line-height per keypress, nav4.x moves ~2.3, and ie5 moves ~4.5. (This was also noted in that other bug). cc: evaughan for now, although (assuming this is not a technical issue), then maybe the UE folks can offer guidance on what the setting should be.

->evaughan as p3/moz0.8, cc german

Waitaminute. Henri was talking about the down button on the scrollbar, but jrgm's figures are `per keypress'. Is there a difference in speed between the two? Why/ why not? I'd suggest that the scrollbar button should work at the same speed as the down arrow key, which should be x em/second, where x is the key repeat speed set in your `Keyboard' control panel or equivalent, and em is for your `Normal' font as set in prefs.

I think that, above, I meant 'scrollbarbar-button-click' not 'keypress'. I previously did some more careful measurements on bug 56683, and keypress is "faster" than scrollbar-button. I don't know why that would be (although Nav4.x had the same proportional difference). > should be x em/second, where x is the key repeat speed set in your `Keyboard' > control panel or equivalent, and em is for your `Normal' font as set in prefs Er. My point is that the difference in apparent speed is tied to 'how many lines are scrolled per event'. Other browsers scroll >1.0em per event, which makes them "faster". Mozilla currently moves at ~1.0em per event, which makes it "slower".

->moz0.9

John is exactly right; the default scroll value is 1 unless the increment is specified (http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsSliderFrame.cpp#1 85). MouseClicked() is called both when holding the mousebutton down (during which it's called on a timer) and just on a simple click of the button. Do we want the increment for scrolling with the button down and simple clicks to be the same? It seems to be, on Windows.

->dr, see evaughan for how to fix this.

Ok, this is going to be kind of a pain in the butt. The scrollbar buttons use nsRepeatService to determine repeat rates. They're currently hardcoded in nsRepeatService, but what I need to do is add two metrics for them into nsILookAndFeel, and have nsRepeatService access those. The pain-in-the-butt part will be implementing accessing those metrics for each platform. I notice an nsXPLookAndFeel, which is used by several or all of the platform LookAndFeel implementations, but I'm not sure I'll be able to take advantage of that. I'll try to grok further...

nsILookAndFeel is actually extremely easy to work with (I can help if you need), but where do you see these hardcoded values. Looking at http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsSliderFrame.cpp#18 5, it seems as if the hardcoded value is only a default to fallback on if the "increment" attribute isn't set on the nsSliderFrame.

Oh, no, it's not actually about the scroll increment (i.e., what distance the nsSliderFrame scrolls for each keypress, click, or whatever), it's about the repeat rate. It turns out (and this should *really* have been said earlier in the bug) that we've hardcoded the keyboard repeat rate and mouse click-and-hold repeat rate, and that they really should be getting their values from the system. These are hardcoded here: http://lxr.mozilla.org/seamonkey/source/ layout/xul/base/src/nsRepeatService.cpp#32 This is what needs to be changed. Perhaps we could also change the scroll increment to something larger (2-3 line-heights, rather than one), though. That might give a perceptual improvement.

Ah, I see what you mean. I thought what we wanted here was to scroll more lines each callback (per John's 12/14 comment). Or maybe we actually want a combination of both (tweaking increment amount and repeat length).

If you want to look at repeat rates, fine, but a base reason that our apparent scrolling rate is slow is that we scroll 1em per event. Just click once (or key once) and note the amount of the view that is scrolled.

[spam] pushing off non-critical 0.9.2 bugs to 0.9.3. please take the helpwanted keyword to heart if you'd like to see these fixed in 0.9.2!

[spam] dr@netscape.com's bugs subject to redistribution by chofmann. R!

WFM with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020531 and RC3 Please have a look on bug 100951 ! Any problmes seen (with other OS) to set this bug FIXED or WFM? Can we close this bug ? keywords --> qawanted ?

This bug doesn't seem particularly useful any longer.