NEW 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
https://bugs.webkit.org/show_bug.cgi?id=169509
Summary If a scrollable layer is at its end position and user tries to scroll it with...
Noam Rosenthal
Reported 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.
Attachments
Simple HTML file reproducing the bug (443 bytes, text/html)
2017-03-11 00:32 PST, Noam Rosenthal
no flags
Hack to enable "overscroll-behavior: contain" style behavior (2.14 KB, text/html)
2018-12-10 10:59 PST, jonjohnjohnson
no flags
Simon Fraser (smfr)
Comment 1 2017-03-11 08:44:26 PST
A scroll latching issue.
Noam Rosenthal
Comment 2 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?
Noam Rosenthal
Comment 3 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.
Radar WebKit Bug Importer
Comment 4 2017-09-13 11:37:12 PDT
jonjohnjohnson
Comment 5 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???
Simon Fraser (smfr)
Comment 6 2018-12-10 11:04:57 PST
The latching logic is incorrect.
jonjohnjohnson
Comment 7 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.
jonjohnjohnson
Comment 8 2018-12-10 11:10:29 PST
simon.fraser@apple.com my thoughts about rails/latching??? Or your comment from 2017-03-11?
pm
Comment 9 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.
Tobi Reif
Comment 10 2019-09-30 13:24:07 PDT
It would be great if this could get fixed.
Santeri Kääriäinen
Comment 11 2023-05-10 05:57:19 PDT
Hello, any updates on this?
Note You need to log in before you can comment on or make changes to this bug.