| Summary: | If a scrollable layer is at its end position and user tries to scroll it with a down-scroll gesture, it will not scroll | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Noam Rosenthal <noam> | ||||||
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | Normal | CC: | allllllx, augus.dupin, bbmarelyo, bfulgham, hello+webkitorg, hi, ik, paulo.sousa, pm, santeri.kaariainen, simon.fraser, tobi, webkit-bug-importer, wenson_hsieh, zalan | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
A scroll latching issue. @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? 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. 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??? The latching logic is incorrect. Also, my last comment and test case is about iOS Safari, not desktop, that may not have been at all clear. simon.fraser@apple.com my thoughts about rails/latching??? Or your comment from 2017-03-11? 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. It would be great if this could get fixed. Hello, any updates on this? |
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.