Bug 118175 – Maximum scroll position can be negative with reverse pagination

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Tim Horton]

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.

[Radar WebKit Bug Importer]

<rdar://problem/14301217>

[Tim Horton]

Created attachment 205690 [details]
preliminary

[Tim Horton]

Created attachment 205758 [details]
patch

Going to try to figure out if this is testable now.

[Tim Horton]

(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]

(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]

Created attachment 205836 [details]
patch

[Tim Horton]

http://trac.webkit.org/changeset/152265