Bug 118175

Summary: Maximum scroll position can be negative with reverse pagination
Product: WebKit Reporter: Tim Horton <thorton>
Component: Layout and RenderingAssignee: Tim Horton <thorton>
Status: RESOLVED FIXED    
Severity: Normal CC: bdakin, hyatt, sam, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
preliminary
none
patch
none
patch andersca: review+

Tim Horton
Reported 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.
Attachments
preliminary (2.47 KB, patch)
2013-06-28 03:19 PDT, Tim Horton 		no flags
DetailsFormatted DiffDiff
patch (3.52 KB, patch)
2013-06-28 16:57 PDT, Tim Horton 		no flags
DetailsFormatted DiffDiff
patch (23.47 KB, patch)
2013-07-01 14:23 PDT, Tim Horton 		andersca: review+
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2013-06-28 02:28:34 PDT
<rdar://problem/14301217>
Tim Horton
Comment 2 2013-06-28 03:19:45 PDT
Created attachment 205690 [details] preliminary
Tim Horton
Comment 3 2013-06-28 16:57:06 PDT
Created attachment 205758 [details] patch Going to try to figure out if this is testable now.
Tim Horton
Comment 4 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.
Sam Weinig
Comment 5 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.
Tim Horton
Comment 6 2013-07-01 14:23:56 PDT
Created attachment 205836 [details] patch
Tim Horton
Comment 7 2013-07-01 14:36:26 PDT
http://trac.webkit.org/changeset/152265
Note You need to log in before you can comment on or make changes to this bug.