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

• Component: Layout and Rendering
• Status: NEW

[Noam Rosenthal]

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.

[Simon Fraser (smfr)]

A scroll latching issue.

[Noam Rosenthal]

@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]

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]

<rdar://problem/34415267>

[jonjohnjohnson]

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 [e-mail] 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 [e-mail]?) 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)]

The latching logic is incorrect.

[jonjohnjohnson]

Also, my last comment and test case is about iOS Safari, not desktop, that may not have been at all clear.

[jonjohnjohnson]

[e-mail] 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.

[Tobi Reif]

It would be great if this could get fixed.

[Santeri Kääriäinen]

Hello, any updates on this?

[Dave Normington]

Our users are experiencing this issue with ag-grid while in PWA standalone mode. We serve our internal webapp to users as a PWA and found this issue is present but not there when accessing the webapp directly via URL. It does seem that the ripstop fix does solve the issue but obviously would like it to be solved at the root. Is anyone interested in looking at this? Is there another way for this to get prioritised?

Thanks for your help

[Simon Fraser (smfr)]

Dave, are you seeing this on macOS or iOS?

[Dave Normington]

On iPadOS thanks Simon

[Simon Fraser (smfr)]

I think that's a different issue.