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 wenson_hsieh@apple.com 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.
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.
Created attachment 355350 [details] Simple testcase
Heh, RenderLayer::visibleContentRectInternal() has: // FIXME: This seems wrong: m_layerSize includes borders. Can we just use the ScrollableArea implementation?
Created attachment 355364 [details] Patch
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
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
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!!!
<rdar://problem/46283201>
https://trac.webkit.org/r238576
\( ゚ヮ゚)/ Thanks for being so speedy simon.fraser@apple.com & dino@apple.com