90852 - Scrolling step size should be proportional to window height for v.short windows.

Status: NEW

(Core :: XUL, defect)

Description

[armccurdy]

Open a brower window and resize until visible height reaches the point at which 
the scroll bar disappears. Now try scrolling (with either arrow keys or mouse 
wheel).

The amount of scrolling per up/down arrow keypress or mouse wheel click is 
greater than the amount of visible area height, meaning that some parts of the 
page are never displayed.

IE handles this much better.

Bug 33966 seems related.

Comment 1

[John Morrison]

Seems to be scrolling at about one 'em', the same as usual on windows. IE does
set the multiple of line-heights scrolled per keypress as proportional to the
total height of the window. I wouldn't describe that as better, but I do 
prefer the number of lines scrolled to be greater than one (which is bug 
60986). That bug can be fixed by either setting the lines-per-keypress to 
some constant > 1, or make it adaptive to viewport height (as noted in this 
bug). 

-> dr, Future (but (a) let's fix this soon, and (b) you can mark this as a 
duplicate of bug 60986).

Comment 2

[armccurdy]

Although it relates to bug 60986, I'm not sure that its really a duplicate ?

For windows with very small heights (eg one line of text), IE seems to make the 
scroll step size is a few *pixels* (ie a fraction of an 'em' rather than a 
multiple). This increases scrolling resolution, but (greatly) reduces 
scrolling 'speed'.

Therefore a possible fix for bug 60986 (scrolling by greater than 1 'em' per 
scroll event) would make this bug worse.

Comment 3

[John Morrison]

You are literally correct in your observations. I just fail to see the utility
in scrolling by 1 or 2 pixels per keypress. But, then again, I am UE 
challenged.

Comment 4

[John Morrison]

Um, with that said, I'm not opposed to seeing this implemented as "proportional 
to viewport height" (which is why I said to dup it: what I really meant is 
that if that is what is done (proportional) then this bug is a dup; if it is
done as 'constant', then this bug can stay open as an RFE, I suppose).

Comment 5

[armccurdy]

Personally, for normal sized windows, I quite like the current scrolling 
features (if the up/down arrows don't go fast enough for you, use pgup/pgdown, 
the mouse scroll wheel, or drag the scrollbar :-) so don't really agree with 
much of bug 60986.

However, I do think there is a problem with very short windows when the amount 
of scrolling that results from an up/down arrow or a mouse wheel click is 
greater than the amount of scrolling that results from a pgup/pgdown.

Comment 6

[Chad Austin]

This is a very special case where the window's vertical height is *very* small.
 I can see this being used possibly in an embedding case where we'd have a
document being shown in a small widget in a dialog, and scrolling in it with
they keyboard would slide the document a few pixels at a time.

Comment 7

[Dan Rosen]

Alright, the way I'd like to do this is to have a threshold of some sort, above
which we scroll "normally" (some number of lines) and below which we scroll
proportionally to the window size. I won't dup this, though the patch I make for
60986 ought to fix this.

Comment 8

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 9

[Dan Rosen]

[spam] [e-mail]'s bugs subject to redistribution by chofmann. R!

Comment 10

[RNicoletto]

This is WFM.
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.