If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

arrowscrollbox does not work properly on lists > 2 x height




15 years ago
9 years ago


(Reporter: Bob Wilson, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)




15 years ago
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.
Ever confirmed: true

Comment 2

15 years ago
Confirmed; also, when I make browser window 3 items high, I cant scroll down
anymore as the arrow disappears.

Comment 3

15 years ago
I can see your point, but is there somewhere in the mozilla UI that this is 
No, I don't think so. Why ? :)
Perhaps the bookmark menu uses this, if it gets to long.. I don't know.

Comment 5

15 years ago
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?

Comment 6

12 years ago
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).

Comment 7

12 years ago
Maybe it should scroll by a certain fraction of its scrolled height?

Comment 8

12 years ago
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.


9 years ago
Assignee: jag → nobody
You need to log in before you can comment on or make changes to this bug.