Bug 191322

Summary: Momentum scrolling ends at the wrong place when a scrolling overflow element has a non-zero border
Product: WebKit Reporter: jonjohnjohnson <hi>
Component: Layout and RenderingAssignee: Simon Fraser (smfr) <simon.fraser>
Severity: Normal CC: bfulgham, dino, ews-watchlist, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Macintosh   
OS: macOS 10.12   
Description Flags
Simple testcase
dino: review+, ews-watchlist: commit-queue-
Archive of layout-test-results from ews124 for ios-simulator-wk2 none

Description jonjohnjohnson 2018-11-06 12:36:36 PST
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.

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

Scrolling that "feels" as though it should reach the end of the scrolling container should not fall *just short of reaching the end.
Comment 1 jonjohnjohnson 2018-11-18 05:23:11 PST
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:

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.
Comment 2 Simon Fraser (smfr) 2018-11-20 09:59:04 PST
Created attachment 355350 [details]
Simple testcase
Comment 3 Simon Fraser (smfr) 2018-11-20 10:23:28 PST
Heh, RenderLayer::visibleContentRectInternal() has:

    // FIXME: This seems wrong: m_layerSize includes borders. Can we just use the ScrollableArea implementation?
Comment 4 Simon Fraser (smfr) 2018-11-20 14:17:27 PST
Created attachment 355364 [details]
Comment 5 EWS Watchlist 2018-11-20 16:54:18 PST
Comment on attachment 355364 [details]

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

New failing tests:
Comment 6 EWS Watchlist 2018-11-20 16:54:19 PST
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 7 Dean Jackson 2018-11-23 09:50:51 PST
Comment on attachment 355364 [details]

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() {

Comment 8 Radar WebKit Bug Importer 2018-11-27 11:48:38 PST
Comment 9 Simon Fraser (smfr) 2018-11-27 14:03:37 PST
Comment 10 jonjohnjohnson 2018-11-27 14:39:35 PST
\( ゚ヮ゚)/

Thanks for being so speedy simon.fraser@apple.com & dino@apple.com