Bisect points to https://chromium.googlesource.com/chromium/src/+log/aa4c8d53d645e611a5924f130a435e3376eae675..ff81df7cbfc3362d60ea0fac8be9b0558d60e857

https://chromium.googlesource.com/chromium/src/+/f53825a1fb92e74b9a889b9501243e03de57094d looks like the only scrolling-related commit.

sahel@: Could you triage?

I couldn't reproduce it on 64.0.3249.0 (Developer Build) (64-bit).
lgarron@ could you please try it with the latest build?

I can't observe it in my Canary *installation*, but I do observe it in a bisect containing the same build.

Now that TouchpadAndWheelScrollLatching and AsyncWheelEvents are enabled by default, is it possible that you can't reproduce because they are disabled via Finch?

I tried it with all 3 possible finch cases: 1)both async_wheel_event and wheel_scroll_latching disabled, 2) only wheel_scroll_latching enabled, 3) both flags enabled. Regardless of the flag values I couldn't reproduce it on the latest build.

Hmm, I can definitely still repro on my latest dev update (Chrome 63.0.3239.18).

Unable to reproduce the issue in MacBook Pro (Retina, 15-inch, Mid 2014), 10.12.6 and macbook air using chrome reported version #63.0.3239.9, latest chrome dev #63.0.3239.18 and latest canary #64.0.3249.0.

Following are the steps followed to reproduce the issue.
------------
(1) Visited https://chromium-review.googlesource.com/c/chromium/src/+/625337 and badssl.com.
(2) Scrolled till end of the page as per the attached scroll.mov in comment #0.
(3) Observed that the scrolling stopped at the end of the page as expected.

Attaching screen cast for reference.

lgarron@ - Could you please check the screencast and please let us know if anything missed from our side.

Thanks...!!

Deleted: 776962.mp4 3.5 MB

	776962.mp4 3.5 MB View Download

Let's wait until Chrome 64 reaches beta, and I can see if it still repros?

krajshree@: Actually, it looks like you *are* triggering the same behaviour I am; my mouse just scrolls farther. Chrome Stable does not scroll a single pixel above the blue header bar.

I can still reproduce on 64.0.3251.0 Dev but not Chrome 64.0.3247.0 Canary.

It seems that this behaviour happens when TouchpadAndWheelScrollLatching is enabled.

sahel@: Is this intended behaviour of the feature?

If we're intending to implement iOS-style overscroll (which Safari doesn't support?), I would expect it to be limited at some reasonable fraction less than the page size.

The video at comment #7 shows the rubber banding effect which is supported.
With wheel scroll latching disabled rubber banding is broken in some cases( crbug.com/628742 ) enabling latching fixes the issue.

lgarron@ if what you see is different from the video at comment #7, please post a screencast.

Thanks

Seeing similar behavior in:

64.0.3255.0 (Official Build) canary (64-bit)
64.0.3256.0 (Official Build) canary (64-bit)

on MacOS 10.12.6 and Wacom Desktop Center 6.3.15-3.  Overscrolling with a Wacom tablet feels terrible - you slowly scroll way into white gutters above/below the page's content, and then it snaps back.  Screencast attached.

Deleted: canary-overscroll-wacom.mov 28.5 MB

canary-overscroll-wacom.mov 28.5 MB Download

brentons@ please send the variations list as well.

> lgarron@ if what you see is different from the video at comment #7, please post a screencast.

I believe I observe the same.

The problem is that there are mice that will *keep scrolling* for a while after you let them go. Instead of rubber banding to a fixed point (or asymptote), the page just keeps scrolling out of view at constant velocity. This is unintuitive and inconvenient for those who are used to using this scroll gesture to get the top of the page.

(It's also possible to do the same horizontally, which often reveals sidebar overflow and formatting quirks that are presumably not meant to be visible to the user.

Would it be easy to introduce a maximum scroll distance or to introduce heavy scroll friction after going just past the bounds of the page?

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

commit 9984945dbe893379b16d01093c5cd30801ff782e
Author: sahel <sahel@chromium.org>
Date: Tue Nov 21 21:00:35 2017

Scrolling with Mac mouse don't cause rubber banding.

This cl marks GSB and GSE events that are generated from wheel events
with timer based phaseBegan and phaseEnded as synthetic.
This change is necessary to avoid rubber banding effect while scrolling
by a Mac mouse or any other device that don't provide wheel phase info.

Bug:  776962 
Test: RenderWidgetHostViewMacWithWheelScrollLatchingEnabledTest.TimerBasedPhaseInfo
Change-Id: I51b318fd2790d39939d41dad2539c788bd6430eb
Reviewed-on: https://chromium-review.googlesource.com/779659
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518389}
[modify] https://crrev.com/9984945dbe893379b16d01093c5cd30801ff782e/content/browser/renderer_host/input/mouse_wheel_event_queue.cc
[modify] https://crrev.com/9984945dbe893379b16d01093c5cd30801ff782e/content/browser/renderer_host/input/mouse_wheel_event_queue.h
[modify] https://crrev.com/9984945dbe893379b16d01093c5cd30801ff782e/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc
[modify] https://crrev.com/9984945dbe893379b16d01093c5cd30801ff782e/content/browser/renderer_host/render_widget_host_view_mac_unittest.mm