Bug 169509 - If a scrollable layer is at its end position and user tries to scroll it with a down-scroll gesture, it will not scroll
Summary: If a scrollable layer is at its end position and user tries to scroll it with...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-03-11 00:32 PST by Noam Rosenthal
Modified: 2021-08-09 09:31 PDT (History)
13 users (show)

See Also:


Attachments
Simple HTML file reproducing the bug (443 bytes, text/html)
2017-03-11 00:32 PST, Noam Rosenthal
no flags Details
Hack to enable "overscroll-behavior: contain" style behavior (2.14 KB, text/html)
2018-12-10 10:59 PST, jonjohnjohnson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Noam Rosenthal 2017-03-11 00:32:04 PST
Created attachment 304142 [details]
Simple HTML file reproducing the bug

To reproduce:
- Open the attachment in safari on Mac (nightly, releases, anything)
- Scroll the DIV to the end
- Wait 1-2 seconds until the scrollbars disappears
- Try to scroll by first moving the two fingers downwards and then upwards - works.
- Wait 1-2 more seconds until the scrollbars disappears
- Try to scroll by first moving the two fingers upwards and then upwards - page will scroll instead of the scroll layer.

Seems like the code is set up so that when the beginning gesture is "dead end" it will not bind the touch scrolling to the layer at all.
Comment 1 Simon Fraser (smfr) 2017-03-11 08:44:26 PST
A scroll latching issue.
Comment 2 Noam Rosenthal 2017-03-11 10:48:17 PST
@smfr Exactly, seems like ScrollAnimator::handleWheelEvent returns false when you start 
 scrolling in the wrong direction, and then assigns the frame to stopElement. 
Maybe in a case like this one (where scroll is possible in the opposite direction) ScrollAnimator and friends should return true but not actually scroll, or alternatively return a value that would signal EventHandler to not latch?
Comment 3 Noam Rosenthal 2017-03-11 10:52:23 PST
We've encountered this on several occasions and the workaround do is to listen to onScroll and set the scrollTop to always be either 1 or (end of scroll - 1). I wonder if more people are doing this on the web as a workaround for this issue... I think I saw some that kind of code in JS frameworks.
Comment 4 Radar WebKit Bug Importer 2017-09-13 11:37:12 PDT
<rdar://problem/34415267>
Comment 5 jonjohnjohnson 2018-12-10 10:59:28 PST
Created attachment 356972 [details]
Hack to enable "overscroll-behavior: contain" style behavior

The test case attached shows a "workaround" for this, even if it has the quirk of what some folks know as "scroll-rails" (courtesy of ms/ie) on latching horizontal scroll gestures, locking up vertical scrolling until the test cases "hidden" horizontal scroll container animates to a stop.

It shows the only non-javascript way to fix webkits lack of an "overscroll-behavior" property (Or even if your work on the css side of pointerEvents would make use of the "touch-action" property?). But requires quite a few extra elements/pseudos, an extra scroll container, and the use of quite constrained sticky positioning.

I think what noam@webkit.org is referring to for javascript "1px short of scroll boundaries" would be things like https://github.com/ecto/ripstop.

And I know there are many articles out there about this, especially attempting to work around modals like https://benfrain.com/preventing-body-scroll-for-modals-in-ios/ when iOS fixed positioning still enables scroll chaining unlike most desktop environments.

I haven't wanted to share this with any other devs for fear of such a messy hack becoming used all over, but figured I'd share here, even while I use less reduced versions of this hack in production myself.

If anything, could I get a response from anyone (maybe fred.wang@free.fr?) in the know about how/if your implementation of "overscroll-behavior" (https://bugs.webkit.org/show_bug.cgi?id=176454) will relate to this issue???
Comment 6 Simon Fraser (smfr) 2018-12-10 11:04:57 PST
The latching logic is incorrect.
Comment 7 jonjohnjohnson 2018-12-10 11:08:23 PST
Also, my last comment and test case is about iOS Safari, not desktop, that may not have been at all clear.
Comment 8 jonjohnjohnson 2018-12-10 11:10:29 PST
simon.fraser@apple.com my thoughts about rails/latching??? Or your comment from 2017-03-11?
Comment 9 pm 2019-04-05 06:36:57 PDT
As PWA's become more prevalent and safari looks to support them perhaps this should be re-prioritised. 

It is common for single page applications to have fixed areas to mimic native applications look and feel using scrollable layers for content between the fixed areas.   If going past the boundaries of the scrollable area starting at a boundary as described by Noam the scroll moves to the parent elements of the page.  It becomes unresponsive until the hidden scroll bounces back.
Comment 10 Tobi Reif 2019-09-30 13:24:07 PDT
It would be great if this could get fixed.