159322 - arrowscrollbox does not work properly on lists > 2 x height

Status: NEW

(Core :: XUL, defect)

Description

[Bob Wilson]

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.

Comment 1

[Vidar Haarr (not reading bugmail)]

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.

Comment 2

[Wesha]

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

Comment 3

[John Morrison]

I can see your point, but is there somewhere in the mozilla UI that this is 
apparent?

Comment 4

[Vidar Haarr (not reading bugmail)]

No, I don't think so. Why ? :)
Perhaps the bookmark menu uses this, if it gets to long.. I don't know.

Comment 5

[Bob Wilson]

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

[Håkan Waara]

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

[[e-mail]]

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

Comment 8

[Matthew T (active 1999-2002)]

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.