11751 - Page down/Page up keys don't scroll far enough

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Jerry Baker]

Using 8-11-99 build on Win98 SE, clicking the vertical scrollbar below the
slider (to do a page down) scrolls too far. The problem is that it scrolls
*exactly* 1 page down. Thus, if there is a line of text at the bottom of the
screen where only the top half is visible, after the page down only the bottom
half of that text is visible. This means that the line is never easily readable,
so Mozilla is effectively skipping a line with page downs in some cases.

Comment 1

[Peter Trudelle]

Even the mature browsers have problems with this, although we should be able to
provide a solution for scrollable areas that contain plain text.
reassigning to evaughan

Comment 2

[Jerry Baker]

Netscape 4.61 does not exhibit this behavior. It appears to scroll down by
slightly less than 1 full page.

Comment 3

[Eric Vaughan]

Gfx scrollbars are landing and fix this.

Comment 4

[Jerry Baker]

Not fixed as of build 1999092013

Comment 5

[Sean Richardson]

GFX scrollbars do indeed fix this problem, but, hey, too much!
(Edit>Preferences>Debug Pane> GFX Scrollbars to toggle)

From applications that mostly do this right, I've been trained to
look about 1 to 1 and 1/2 lines below the top of the window
after a [Page Down] to see the line that was just above the
bottom of the window beforehand. Currently, I need to look
3 to 4 lines down. Even after playing with this for a few minutes
it was still disorienting to need to look a few lines away from
where I'd expect to see that line. Same thing for [Page Up], of course.
Clicking above or below the slider does exactly the same thing.

Tested with:
Windows NT, mozilla.exe, 1999-10-20-08-M11 build.

Comment 6

[Peter Trudelle]

mass-moving all m13 bugs to m14

Comment 7

[leger]

Setting QA Contact.

Comment 8

[Eugene Moon]

I just d/l'd Build 1999121708 for the Mac and it seems that scrolling w/
PageUp/PageDn works "the way things are supposed to" and differently from
clicking in the scrollbar. Would it be possible for them to use the same method
and easily resolve this b

Comment 9

[Eugene Moon]

[I hate it when Bugzilla truncates my comments]

... to use the same method and easily resolve this bug?

Comment 10

[Sean Richardson]

Ouch. Like what [e-mail] saw on the Mac, on WinNT, scrolling by [PgUp]/
[PgDn] and by clicking above/below the scrollbar slider (with GFX scrollbars on)
do not scroll the same distance. The scrolling distance no longer creates a 3-4
line overlap; paging in the scrollbar creates about a 1-line overlap, while
paging by [PgDn] creates about a 2-line overlap.

If the aim here is to as often as possible have the last fully-visible line
at the bottom before paging down be the first fully-visible line at the top
after paging down, the proper overlap would be about 1-1/2 lines. With a 1-line
overlap, sometimes the last full line is no longer fully visible after paging
down, and with a 2-line overlap, sometimes the topmost fully visible line after
paging down is the second-last line of the previous "page", not the last line.

Tested with: 2000-01-09-08-M13 nightly binary on Windows NT 4.0sp3.

NOTE: bug 5327, "scrolling down by pages behaves differently then legacy...",
filed against the "Compositor" component, has now been assigned. Other than the
component it looks like a report of the same problem -- if the same code
handles scrolling in all Mozilla apps, there is no point in two engineers
working on it; conversely, if the exact same code is not being called from all
apps, each page-scrolling implementation should work exactly the same.

Comment 11

[Claudius Gayle]

*** Bug 5327 has been marked as a duplicate of this bug. ***

Comment 12

[Eric Vaughan]

targeting

Comment 13

[Peter Trudelle]

Mass moving M17 bugs to M18

Comment 14

[Sean Richardson]

[PgDn] still scrolling a different amount than clicking below the slider
using 2000-05-22 build on WinNT; neither is quite right by UI expectations. 

Nominating for nsbeta3.

Comment 15

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 16

[Peter Trudelle]

nsbeta3-

Comment 17

[Sean Richardson]

Retested using 2000-08-01-08-M18; exactly the same as before.

Adding 4xp and correctness keywords, because this is one of those areas where
repeated interaction with other programmes (including NN 4.x and earlier)
will have trained users at a subconsicous, almost implicit, level to move
their eyes to a specific position after page-scrolling, no matter what the
app, platform, or OS, and Mozilla is not conforming to those implicit 
expectations.
 
This is also a correctness issue because Mozilla does not guarantee that the
last fully visible line before paging down will still be fully visible after
paging down. Many users will page down when they reach the end of a sentence
in the middle of the last completely visible line, expecting to start reading 
again with all of the next sentence in view at once.

Chaging Platform and OS to All/All; the same behaviour belongs cross-platform.

Adding helpwanted, hoping that someone can make a quick and risk-free patch for
this to get it in before shipping.

Comment 18

[djk]

I think I may have found why [PgDn] and the scrollbar behave differently.  There
is a function called ScrollByPages that is defined as a function for two
classes: class nsScrollPortView and class nsScrollingView.

From a quick glance at the two functions, it looks like
nsScrollPortView::ScrollByPages will do really well for scrolling (and
readability) if the number of pages to be scrolled is 1 or -1, as it uses a
defined percentage of page height to jump by.  Any different number of pages
with that function may give odd results because the 'dy' (amount to jump) is
first based on the percentage and *then* multiplied by the number of pages to
jump.  Judging from the decent behavior of [PgDn], I guess it uses this function.

nsScrollingView::ScrollByPages seems to do pretty much what it says, without
regard for readability.  It just does a straight multiplication and addition to
get the new position to scroll to.  I guess multiple page jumps using the
routine would produce more expected results due to the lack of a percentage
multiplier.

my $0.02

Comment 19

[Reinout van Schouwen]

I thought I should mention this - perhaps worth opening a new bug for??
Page Down will only scroll down one page, even if you keep it pressed down, in
which case I would expect the page to keep scrolling. What do you think?

Comment 20

[Claudius Gayle]

Reinout, I'm not sure that is a bug, if it were a bug it would definitely be a diffenent bug,
probably in the keyboard navigation component.

Comment 21

[Simon Fraser [no longer active]]

I find that the Page Down key, and clicking in the page scroll area of the 
scrollbar, do different things here. The former seems to simply repeat a fixed 
number of pixels of content (which repeats about 4-5 lines of normal-sized text). 
This makes it hard to find ones place when reading. But clicking in the scroll 
bar to move down by a page does the correct thing; it repeats the last line of 
text after the scroll.

So I think the more broken scrolling is Page Down key scroll.

Comment 22

[Simon Fraser [no longer active]]

Scrolling via page up/page down go via nsScrollPortView::ScrollByPages(), and 
scroll 90% of the view's height.

Scrolling via the scrollbar happens via nsSliderFrame::PageUpDown, which gets the 
scroll amount from the pageincrement attribute on the scrollbar box. This is set 
to be height-lineHeight, which is correct.

Can't we just hook the events up so that Page Down goes through the same code 
path?

Comment 23

[Simon Fraser [no longer active]]

This is catfood for me. I easily can't read long text pages with this bug.

Comment 24

[djk]

Upon further testing, I agree that the Page Down code is more broken; the
scrollbar page down is more readable for me.

Comment 25

[Eugene Savitsky]

Look at bug 94893. It discribes the PgDn/PgUp problem. And the scrollbar scrolls
the page exactly as it should! 

Should we close the 94893 and re-summary this one or...?

Comment 26

[Simon Fraser [no longer active]]

Adjust summary.

Comment 27

[Simon Fraser [no longer active]]

*** Bug 94893 has been marked as a duplicate of this bug. ***

Comment 28

[sairuh (rarely reading bugmail)]

->bryner or saari?

Comment 29

[Brian Ryner (not reading)]

Tested this just now and we do scroll slightly less than a full page, so we're
not skipping any lines.

Comment 30

[Simon Fraser [no longer active]]

This is not fixed; see my comments above:

> Scrolling via page up/page down go via
> nsScrollPortView::ScrollByPages(), and scroll 90% of the view's height.
> 
> Scrolling via the scrollbar happens via nsSliderFrame::PageUpDown,
> which gets the scroll amount from the pageincrement attribute on the
> scrollbar box. This is set to be height-lineHeight, which is correct.
> 
> Can't we just hook the events up so that Page Down goes through the
> same code path?

To reiterate: the page up/page down keys scroll by a fixed proportion of 90% of 
the visible area, which is not sufficient when you're reading long pages of small 
text, because it will repeat several lines, making it hard to find your place 
again. The code should do what the scrollbar code does (ideally by going through 
the same code path) -- it should get the line height, and scroll by the view 
height-lineheight.

Comment 31

[Simon Fraser [no longer active]]

I also consider it a bug that scrolling with page up/page down, and with the page 
up/down areas on the scrollbar move by different amounts. The behaviour needs to 
be the same.

Comment 32

[Eugene Savitsky]

Just wanted to reopen... Simon is right.

Comment 33

[Brian Ryner (not reading)]

Ok, this bug morphed... the original report is _only_ talking about the amount
scrolled when you click in the scrollbar.

Comment 34

[Alex Vincent [:WeirdAl]]

Bug 103981 is probably related to this one.  Uncertain if it's a dupe of this
bug, though.  :)

Comment 35

[Jerry Baker]

Mass removing self from CC list.

Comment 36

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.

Comment 37

[Simon Fraser [no longer active]]

I still see complains about this (in Chimera, for example). Can we factor the
code that scrolls by "pagefulls" from the scrollbar, and from key events? They
should use the same code (the code that trys to scroll by the height of the view
minus the height of a line of body text), rather than the broken code that
scrolls by 90% of the view height.

Comment 38

[Aaron Leventhal]

Another problem related to page down when reading long documents is bug 168214.
It suggests a line or some kind of marker so that you can see where on the
screen the next line is.

Comment 39

[Wayne Mery (:wsmwk)]

WFM with FF 2. and also Bug 103981.  Do you agree?

Comment 40

[Wayne Mery (:wsmwk)]

~ no response
don't see this with or without, find bar, status bar
=> WFM