|Summary:||Maximum scroll position can be negative with reverse pagination|
|Product:||WebKit||Reporter:||Tim Horton <thorton>|
|Component:||Layout and Rendering||Assignee:||Tim Horton <thorton>|
|Severity:||Normal||CC:||bdakin, hyatt, sam, simon.fraser, webkit-bug-importer|
|Version:||528+ (Nightly build)|
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 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.