Bug 191322 – Momentum scrolling ends at the wrong place when a scrolling overflow element has a non-zero border

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[jonjohnjohnson]

Firstly, I'm sorry that this isn't as reduced of a test case as I, or probably you guys, would like, but I've struggled to isolate it apart from using negative margins of large/viewport units in conjunction with the sticky positioning scheme...

cc [e-mail]

1. Go to test case -> https://jsbin.com/votodew/edit?css,output in large enough screen see it's background as white.
2. Scroll down through the red bordered "stacking/sticking" dialogue, reaching the very bottom.
3. Repeat the action of scrolling away from the bottom edge of the scrollHeight.
4. Notice if you sufficiently throw a scrolling gesture to reach scrolling end, but not with excessive force, more often than not, the final resting scroll position, will leave the scrollTop just short of reaching the end of the scroll container.
*Note, the easy visual that notes it not scrolling to the end is that the very last line of the "dialogue" is not aligned with the rest of the text, resting extra pixels below, depending on the viewport height.
5. When it "falls short" you can start another scrolling downward gesture that will reach it's end. But quite often it's miscalculating.

Problem
It seems as though mid scroll action, a sufficient gesture for reaching the calculated "scroll end" is shorter than the elements scrollHeight.

Expectation
Scrolling that "feels" as though it should reach the end of the scrolling container should not fall *just short of reaching the end.

[jonjohnjohnson]

I put more elbow grease into isolating the bug to being from a scroller having a border-width set to any length in the same axis of scrolling.

Here is an replacement (and more concise) test case:
https://jsfiddle.net/9v514o37/

Four scrollers provided, that scroll in the dimension to see lined pattern move through view. Whether horizontal or vertical, reaching the "scrollend" position is chunky and requires extra effort on macOS STP when scrolling in the dimension that also has a border-width value. See the major difference in effort when scrolling blocks that do not have border in that dimension.

Sorry for not isolating as well or even correctly with the first test case. Completely ignore that in light of this comment.

[Simon Fraser (smfr)]

Created attachment 355350 [details]
Simple testcase

[Simon Fraser (smfr)]

Heh, RenderLayer::visibleContentRectInternal() has:

    // FIXME: This seems wrong: m_layerSize includes borders. Can we just use the ScrollableArea implementation?

[Simon Fraser (smfr)]

Created attachment 355364 [details]
Patch

[EWS Watchlist]

Comment on attachment 355364 [details]
Patch

Attachment 355364 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/10092782

New failing tests:
media/no-fullscreen-when-hidden.html
accessibility/ios-simulator/scroll-in-overflow-div.html

[EWS Watchlist]

Created attachment 355370 [details]
Archive of layout-test-results from ews124 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews124  Port: ios-simulator-wk2  Platform: Mac OS X 10.13.6

[Dean Jackson]

Comment on attachment 355364 [details]
Patch

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

> LayoutTests/fast/scrolling/momentum-scroll-with-borders.html:46
> +            let sendMomenumScroll = function() {

momenum!!!

[Radar WebKit Bug Importer]

<rdar://problem/46283201>

[Simon Fraser (smfr)]

https://trac.webkit.org/r238576

[jonjohnjohnson]

\( ﾟヮﾟ)/

Thanks for being so speedy [e-mail] & [e-mail]