Bug 32595 – When scrolling by page, hold back a fraction of the page size

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Peter Kasting]

From WebCore/platform/Scrollbar.h:

const int cAmountToKeepWhenPaging = 40;

This means that when we scroll by "one page", we overlap by 40 px.  This is an extremely small amount -- for any nontrivial window height, barely enough to be noticeable.  For trivially tiny windows this also degenerates badly -- at a height of 41 px, we scroll by 1 px per "page".  (At 40 px and below, we scroll by the height of the window.)

By contrast, IE overlaps by 1/8th of the page height.  This strikes me as much better for readability (and indeed, when reading on my full-height window, it's much easier to read without losing my place).

I'd like to change to this scheme, if there aren't objections.  It would also be good to know if we need to make this behavior platform-dependent (it currently isn't).

[Peter Kasting]

Created attachment 46295 [details]
patch v1

[WebKit Review Bot]

Attachment 46295 [details] did not pass style-queue:

Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
WebCore/platform/Scrollbar.h:43:  One space before end of line comments  [whitespace/comments] [5]
Total errors found: 1

[Peter Kasting]

Created attachment 46302 [details]
patch v2

Fix style nit.

[Eric Seidel (no email)]

Attachment 46302 [details] did not build on mac:
Build output: http://webkit-commit-queue.appspot.com/results/182803

[Peter Kasting]

Created attachment 46411 [details]
patch v3

Try this one.

[Darin Adler]

Comment on attachment 46411 [details]
patch v3

I haven't had a chance to review, but my first thought is that this patch changes WebCore, but leaves the Mac OS X WebKit code that does the same thing with the old behavior. It would be better to keep the two consistent.

[Peter Kasting]

(In reply to comment #6)
> (From update of attachment 46411 [details])
> I haven't had a chance to review, but my first thought is that this patch
> changes WebCore, but leaves the Mac OS X WebKit code that does the same thing
> with the old behavior. It would be better to keep the two consistent.

I agree, but I didn't know that there was code in WebKit that did this.  I hadn't found any references to this constant there, just to the line-scrolling size.  Do you know where the relevant code is?

[Peter Kasting]

Created attachment 46627 [details]
patch v4

Added a blind change to the Mac code to keep things in sync.

[Eric Seidel (no email)]

Attachment 46627 [details] did not build on mac:
Build output: http://webkit-commit-queue.appspot.com/results/186829

[Peter Kasting]

Created attachment 46630 [details]
patch v5

That's interesting, I wouldn't have thought Scrollbar.h would be in scope... if it is, I can just use that set of constants everywhere.  Let's see if this patch compiles on Mac.

[Dave Hyatt]

Comment on attachment 46630 [details]
patch v5

r=me

[Peter Kasting]

Fixed in r53718.

[Dimitri Glazkov (Google)]

This patch introduced bunches of pixel test failures -- all trivial changes to the size of the scrollbar handle.

I was tempted to roll out but, Peter persuaded me to let him fix the problem as a follow-up patch, since the patch revealed a possible bug in another place. Bug 34049 filed to fix it.

[Dan Root]

Please consider backing this out or providing another method to determine page overlap on scrolling.

40 px an extremely small amount for any nontrivial window height, but the conversion to a page percentage provides absolutely horrible user experience when reading long pages of prose text on large (tall) browser windows.

I have a 1600 pixel tall display, and run my browser window that full height.   When I scroll down a page, that means that approximately 200 pixels of overlap occur.  Using a standard fonts, that means that I'm getting around 12-14 lines of overlapping text.   Even on more modest displays, it can be 8-10 lines of overlapping text.   That can be several inches of text that I have to rescan in order to find where I left off reading at the bottom of the previous "page".

On pages with plenty of visual structure, this doesn't seem bad, but on pages that do not have any sort of texture to provide context, the user has to rescan a full 1/8th of a page of text just to find where they left off, instead of being able to use the visual cues provided by the window itself.  This makes reading long blocks of prose especially painful.  Ideally for these use cases there should be no more than about two lines of overlap.  Just enough to be able to ensure context and that more than one "page" was not skipped by accident.  Conveniently, 40px is 2-3 lines of text at standard font sizes, just about right for comfortable scanning.

(In reply to comment #14)
> Please consider backing this out or providing another method to determine page overlap on scrolling.

See bug 34371.

> 40 px an extremely small amount for any nontrivial window height, but the conversion to a page percentage provides absolutely horrible user experience when reading long pages of prose text on large (tall) browser windows.

I agree. <http://trac.webkit.org/projects/webkit/changeset/54345> re-instated the 40px cap on Mac OS X.

[Peter Kasting]

When looking solely at overlap, it makes sense to me to tune for the common case, which is where there are at least a few visually identifiable features in or around the content; in such scenarios, an increased overlap value makes it easier to quickly relocate one's position.

However, instead of focusing on tuning overlap as the primary means of position location, I think we should work on more effective methods, such as smooth scrolling (which I'm currently working on), or subtle graphical effects (which we Chromium folks have brainstormed a bit but never written a formal bug for-- an example would be that the scrolled-in page region would have a very slight lightening or darkening that would fade away).

[Dan Root]

Either of those options might solve the issue I see, though it'd be hard to say for certain without some usability testing.

But right now, having just come from Firefox and older versions of Safari to a Chromium browser, I was immediately struck by how difficult it was to read long blocks of prose.  Distracting to the point that I actually found it more comfortable to open those pages in an entirely separate browser window resized to the point where 1/8th of the page did not represent such a large amount of duplicated text to re-read every time I hit page down.

[Graeme Hewson]

So, following on after 2½ years from comments #14 to #17, has anything happened about research into the user experience?

I asked about UX here: http://ux.stackexchange.com/questions/28773/guidelines-for-browser-page-overlap. The replies didn't lead on to any solid evidence for how much the overlap should be, so ISTM the user should be allowed to choose.

[Peter Kasting]

(In reply to comment #18)
> So, following on after 2½ years from comments #14 to #17, has anything happened about research into the user experience?
> 
> I asked about UX here: http://ux.stackexchange.com/questions/28773/guidelines-for-browser-page-overlap. The replies didn't lead on to any solid evidence for how much the overlap should be, so ISTM the user should be allowed to choose.

I already addressed this in the other bug where you posted -- see bug 34371 comment 21.

In short, this is configurable by the port as far as WebKit is concerned.  If you want your port maintainer to add a UI hook for controlling this, you'll need to file a bug with that port.  I can tell you in advance that Chromium won't be adding such a hook.