The elements in the centre of an arrowscrollbox are inaccesible if the arrowscrollbox is not of sufficient height. The buttons scroll rapidly through the list and do not permit the user to reliably stop at an intermediate point. For example, an arrowscrollbox containing 15 items but which can only display 4 at a time results in the centre 7 items being virtually inaccessible. The first 4 are initially displayed and when the mouse is placed over the down button the contents are rapidly scrolled until only the last 4 are visible. The converse happens when the mouse is placed over the up button. The arrowscrollbox does not appear to support the 'increment' or 'pageincrement' properties of the scrollbar that would permit better operation.
I agree. Take a look at <http://www.xulplanet.com/tutorials/xultu/examples/ex_5_4_1.xul>, and resize your browser-window to show only 3 of the items at a time. Now try scrolling thru them.. It's /way/ to fast.. and it's very difficult to make it stop on the item you want. Build 2002072408 trunk.
Confirmed; also, when I make browser window 3 items high, I cant scroll down anymore as the arrow disappears.
I can see your point, but is there somewhere in the mozilla UI that this is apparent?
No, I don't think so. Why ? :) Perhaps the bookmark menu uses this, if it gets to long.. I don't know.
It depends what you mean by the 'Mozilla UI'. In terms of Mozilla the browser application then the answer is no, not as far as I am aware. But the arrowscrollbox IS part of the Mozilla UI toolkit for those of us who are writing applications based on Mozilla using XUL, XBL and CSS. Is the requirement for bug fixes that aren't immediately apparent in the browser to be disregarded as second rate?
What would be the desired behaviour here? How fast/slow should the box scroll? Should we implement a speed-property (bloat-warning)? Note that the <arrowscrollbox> is not only used as in the testcase, but also for menus (where maybe you want to scroll fast with a lot of bookmarks).
Maybe it should scroll by a certain fraction of its scrolled height?
I suggest that wherever auto-scrolling occurs, it should act like a jog control: the speed of scrolling should be proportional to the distance between the pointer and the inner edge of the autoscrolling area. If you're on the innermost pixel of the autoscrolling area, scroll at a sedate ~6em/second, increasing to perhaps ten times that if you move right to the top/bottom of the area in which autoscrolling should still be happening. For a menu, "the top/bottom of the area in which autoscrolling should still be happening" means the top/bottom of the screen (bug 63295). For an "arrowscrollbox", I don't know where that top/bottom should be, as I haven't seen a control like this used in real software.