Thank you for opening this. Also this bug happens on both y,x-axis no matter which direction(scrolled all the way up, all the way down, all the way left, all the way right) and it will happen on all scrollable elements(you can see it in action by applying overflow: hidden to html and body)

You say that it's because of scroll latching. Do you know of anyway to force the latching to happen? My workaround was to listen on the touchstart event and move the scrollTop by 1 but is there a more elegant way?

and this bug only happens on touch. Not with mouse scrolling (arrow keys and space bar inputs still propagate to the viewport don't know if this is expected behavior of overscroll-behavior).

re #2: moving scrollTop by 1px ensures that the scroller is always scrollable in that direction and thus it is scrolled and latched to. I am not sure if there is a better way here to force latching. sahel@ will correct me if there is one.

re #3: That is interesting. I would expect this to behave the same for touch/touchpad scrolling which have the same chaining/latching behavior but not keyboard scrolling. The scroll targeting is different for keyboard scrolling and does not involve scroll chaining and latching the same way that we do for touch/touchpad. Similarly overscroll-behavior does not apply for keyboard and scrollbar scrolling.

re #2: The way latching works is to latch to the first element that can scroll in the given direction. If no such element exists the scrolling latches to the viewport. Once this bug is fixed, you can set overscroll-behavior:none for the element to which you want to force latching. In this case we will keep propagating the scroll till either one element can scroll in given direction or we reach the element with overscroll-behavior:none and latch to it regardless of the scroll direction (similar to viewport case).

re #3: Wheel scroll latching is not enabled by default, make sure to enable it from chrome://flags and then try, as majidvp@ mentioned scroll latching for wheel and touch should be the same.

@sahel what flag is it behind?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7d25f2f71326cfddc2c28e559a7f37dc9fe99c8d

commit 7d25f2f71326cfddc2c28e559a7f37dc9fe99c8d
Author: Sandra Sun <sunyunjia@chromium.org>
Date: Thu Jan 04 19:48:46 2018

Latch to the node with non-auto overscroll-behavior

When we overscroll a scroller with non-auto overscroll-behavior at its
scroll extent, no node will be added to the scroll chain, because the
scroller can not consume the current delta. However, if we then scroll
the scroller to the opposite direction in the same gesture, the scroller
won't respond to that because it's not the CurrentlyScrollingNode.

This patch adds the first node with non-auto overscroll-behavior to the
scroll chain regardlessly, as it's the only node we can latch to, even
if it cannot consume the current delta. So when we change the scroll
direction, the scroller can still respond to the later events.

Bug:  798543 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I8baa77ae6690e095de3018cb112185f48f0854a8
Reviewed-on: https://chromium-review.googlesource.com/848314
Reviewed-by: Ali Juma <ajuma@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sandra Sun <sunyunjia@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527068}
[modify] https://crrev.com/7d25f2f71326cfddc2c28e559a7f37dc9fe99c8d/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/7d25f2f71326cfddc2c28e559a7f37dc9fe99c8d/cc/trees/layer_tree_host_impl_unittest.cc
[modify] https://crrev.com/7d25f2f71326cfddc2c28e559a7f37dc9fe99c8d/third_party/WebKit/Source/core/input/OverscrollBehaviorTest.cpp
[modify] https://crrev.com/7d25f2f71326cfddc2c28e559a7f37dc9fe99c8d/third_party/WebKit/Source/core/input/ScrollManager.cpp

When will this fix drop in stable?