Bug 132158 – ScrollingCoordinator is unaware of topContentInset

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

[Brent Fulgham]

The calculation of non-fast-scrollable regions does not currently take the topContentOffset into account. Consequently, the logic that decides whether to stay on the scrolling thread, or drop down to an individual page element, can make the wrong choice. This is especially true for small scrollable regions (such as <select> elements), where the topContentInset may be quite close to the size of the scrollable element itself.

[Brent Fulgham]

<rdar://problem/16706152>

[Brent Fulgham]

Created attachment 230126 [details]
Patch

[Tim Horton]

Comment on attachment 230126 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=230126&action=review

> LayoutTests/platform/mac/fast/scrolling/scroll-select-bottom-test.html:52
> +    //debug("Page before: " + pageScrollPositionBefore + ", select before: " + selectScrollPositionBefore);
> +    //debug("Page after:  " + pageScrollPositionAfter + ", select after: " + selectScrollPositionAfter);

???

[Brent Fulgham]

Comment on attachment 230126 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=230126&action=review

>> LayoutTests/platform/mac/fast/scrolling/scroll-select-bottom-test.html:52
>> +    //debug("Page after:  " + pageScrollPositionAfter + ", select after: " + selectScrollPositionAfter);
> 
> ???

WK1 and WK2 sometimes produce different values here. Rather than baseline both, we comment these out. It's useful to uncommercial them while debugging.

[Brent Fulgham]

(In reply to comment #4)
> (From update of attachment 230126 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=230126&action=review
> 
> >> LayoutTests/platform/mac/fast/scrolling/scroll-select-bottom-test.html:52
> >> +    //debug("Page after:  " + pageScrollPositionAfter + ", select after: " + selectScrollPositionAfter);
> > 
> > ???
> 
> WK1 and WK2 sometimes produce different values here. Rather than baseline both, we comment these out. It's useful to uncommercial them while debugging.

And by uncommercial, I of course mean uncomment them.

[WebKit Commit Bot]

Comment on attachment 230126 [details]
Patch

Clearing flags on attachment: 230126

Committed r167807: <http://trac.webkit.org/changeset/167807>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.