Bug 118175 - Maximum scroll position can be negative with reverse pagination
Summary: Maximum scroll position can be negative with reverse pagination
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-06-28 02:28 PDT by Tim Horton
Modified: 2013-07-01 14:36 PDT (History)
5 users (show)

See Also:


Attachments
preliminary (2.47 KB, patch)
2013-06-28 03:19 PDT, Tim Horton
no flags Details | Formatted Diff | Diff
patch (3.52 KB, patch)
2013-06-28 16:57 PDT, Tim Horton
no flags Details | Formatted Diff | Diff
patch (23.47 KB, patch)
2013-07-01 14:23 PDT, Tim Horton
andersca: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2013-06-28 02:28:20 PDT
When paginated right-to-left or bottom-to-top, the vast majority of the content is in the negative overflow even if the view is capable of fitting the entire document. This was deemed too hard to fix, so instead we need to enable effective scrolling "into the negative" in a few small places.

One such place is ScrollView::maximumScrollPosition, which clamps negative values to zero. This is wrong in the aforementioned case, as the maximum scroll position can be quite negative (indeed, if the view is large enough to contain the entire RTL-paginated document, the maximum and minimum scroll positions will be both equal and equal to the negative scroll origin (ish) -- quite negative).

I'm going to change this just for the RTL/BT pagination cases since it doesn't make sense to change the other already functional cases.
Comment 1 Radar WebKit Bug Importer 2013-06-28 02:28:34 PDT
<rdar://problem/14301217>
Comment 2 Tim Horton 2013-06-28 03:19:45 PDT
Created attachment 205690 [details]
preliminary
Comment 3 Tim Horton 2013-06-28 16:57:06 PDT
Created attachment 205758 [details]
patch

Going to try to figure out if this is testable now.
Comment 4 Tim Horton 2013-06-28 18:19:11 PDT
(In reply to comment #3)
> Created an attachment (id=205758) [details]
> patch
> 
> Going to try to figure out if this is testable now.

I don't think it is unless there's a way to control WKTR's view size.
Comment 5 Sam Weinig 2013-06-28 20:14:32 PDT
(In reply to comment #4)
> (In reply to comment #3)
> > Created an attachment (id=205758) [details] [details]
> > patch
> > 
> > Going to try to figure out if this is testable now.
> 
> I don't think it is unless there's a way to control WKTR's view size.

You can do window.resizeTo() or if that doesn't work test with TWKAPI.
Comment 6 Tim Horton 2013-07-01 14:23:56 PDT
Created attachment 205836 [details]
patch
Comment 7 Tim Horton 2013-07-01 14:36:26 PDT
http://trac.webkit.org/changeset/152265