By the way, besides the bug really nice work on the feature :D

Unable to reproduce the issue on Win-10 precision trackpad laptop using chrome reported version #67.0.3396.62 and latest canary #69.0.3444.0.

Attached a screen cast for reference and gpu_details

Following are the steps followed to reproduce the issue.
------------
1. Used a precision trackpad on windows 10 and navigated to wikipedia.org.
2. Scrolled with two fingers and enough speed to have momentum a webpage.
3. Placed two fingers back in the trackpad surface.
4. Observed that scrolling stopped and there was no opposite scrolling movement.

xaviergonz@ - Could you please check the issue on latest canary #69.0.3444.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 847611.mp4 12.1 MB

	847611.mp4 12.1 MB View Download

Deleted: chrome_gpu@win10.txt 8.3 KB

chrome_gpu@win10.txt 8.3 KB View Download

I did try with a clean profile and chrome canary and still happened with a Dell xps 15.
did you place the two fingers and see it stop while the scroll momentum was still kicking? it's hard to tell from the video. If you want I can make a video myself, but basically what I mean is 

1.scroll with two fingers with speed and lift your fingers up, momentum should kick in and keep scrolling while your fingers are off
2.before momentum scrolling is finished place your two fingers back in the track pad but don't move them, on that moment the momentum scrolling should stop. immediately, but instead it continues until it wears off

You can test the expected behavior both on edge or the start menu list for example, but it is basically the same thing that happens on a smart phone while doing the same set of steps 

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can reproduce this randomly with this step.

1. open chrome.
2. open second chrome.
3. focus second chrome.
4. touchpad pan on first chrome then tap.

Via the logs I am sure we are receiving fling event from direct manipulation api. It may be some undocumented issue related to focus.

I also tested on Edge. I don't experiencing this issue.

sky@ do you have any idea?

Deleted: VID_20180530_105324.mp4 6.9 MB

	VID_20180530_105324.mp4 6.9 MB View Download

Funnily enough I found that if you use for example this page (although it happens with any):
https://chromium.googlesource.com/chromium/src/+/master/ui/gfx/

If you set chrome to full screen (I'm using a hi-dpi resolution screen set to 2x full hd + 200% scaling, not sure if related) and you do the scrolling on the first left third of the page it works, but if you do it on the right 2/3rd of the screen it doesn't.

Also, no matter where I do the two finger tapping, if I let go of it quick enough it will show the right button context menu (I have both tap with one finger to click and tap with two fingers to right click set to on)

By full screen I just mean maximized window by the way

Maybe it is related to this?
https://github.com/chromium/chromium/blob/master/ui/base/win/direct_manipulation.cc

// We only use Direct Manipulation as event handler so we can use any size for
// the fake viewport.
const RECT VIEWPORT_DEFAULT_RECT = {0, 0, 1000, 1000};
...
  hr = viewport_->SetViewportRect(&VIEWPORT_DEFAULT_RECT);
...
  HRESULT hr = viewport_->ZoomToRect(
      static_cast<float>(VIEWPORT_DEFAULT_RECT.left),
      static_cast<float>(VIEWPORT_DEFAULT_RECT.top),
      static_cast<float>(VIEWPORT_DEFAULT_RECT.right),
      static_cast<float>(VIEWPORT_DEFAULT_RECT.bottom), FALSE);


I don't see another setViewport which might be for the non-fake one, so that might explain why it only seems to pick up the first 1000 left pixels of the window and also why it seems to pick up even less of a zone when using a hi-dpi display.

Good catch. Thank you.

Glad to be of help :D
Another thing I just noticed is that if you hit a link which is inside that left zone and start scrolling into the new page it will stop registering scrolling/zoom gestures and the only way to unlock it again is by making a gesture on the right zone.

For example, go to this page:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh768923(v=vs.85).aspx
scroll near the left zone then click on a link
then scroll around again for a while near the left zone, it will stop picking up scrolling events after two or three seconds or so
then do a scroll on the right zone and everything will be back to normal

 Issue 839523  has been merged into this issue.

Just tested again, the scroll locking does not happen in Chrome canary.

However the "left stops momentum vs right doesn't" still applies + tapping to fast to stop momentum opens the context menu.

I can reproduce it on canary randomly. I also have a fix waiting for review.

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

commit 1c01a8d4e41312e1a7c0c7d7e67d6d65f8d86f1a
Author: chaopeng <chaopeng@chromium.org>
Date: Thu May 31 15:32:47 2018

Fix snap fling by tap and unable to scroll for new page on Windows touchpad

The user reported 2 issues in this issue:

1. should stop fling when user tap on touchpad when fling
2. not able to scroll when user click on link to load a slow page then scroll

The first issue is caused by we don't setup the real window size for viewport.
The second issue is caused by we don't stop the viewport before activate
or deactivate the window that may turns the direct manipulation to a unknown
state and stop sending events to chrome.

Bug:  847611 
Change-Id: I646caf9aa70460741cedc1fea7804d8afe14d437
Reviewed-on: https://chromium-review.googlesource.com/1079460
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563247}
[modify] https://crrev.com/1c01a8d4e41312e1a7c0c7d7e67d6d65f8d86f1a/content/browser/renderer_host/legacy_render_widget_host_win.cc
[modify] https://crrev.com/1c01a8d4e41312e1a7c0c7d7e67d6d65f8d86f1a/ui/base/win/direct_manipulation.cc
[modify] https://crrev.com/1c01a8d4e41312e1a7c0c7d7e67d6d65f8d86f1a/ui/base/win/direct_manipulation.h

Actually also one more, showing the context menu when using two fingers tapping to stop the flinch.

This is same as 1. I have tested this case. Please wait for canary for 1~2 days.

Ah cool! Thanks. Just mentioned it because it still happens to me even if I do it inside the 1000x1000 pixels region.

Although I must say in that case it seems to happen if the two fingers to stop are held for like half a second or so. If they are released earlier / later then it doesn't happen.

 Issue 848331  has been merged into this issue.

+craigtumblison@ &  melodychu@ (ConOps POCs), pls let us know if you see a spike in user reports for this issue.

At the moment we're not considering this as M67 stable blocker for further roll out. Pls let us know if there is any concern here. 

chaopeng@, pls update the bug with canary result tomorrow.

#26: Just took a look and we're not seeing sizable feedback on this across our consumer channels. I'm aligned with it not being a ramp blocker, but will let you know if we see any spikes. Thanks!

#28: OK, good to know. Thank you.

Pls request a merge to M68 once change listed at #20 is baked/verified in canary.

For M67 which is already in stable, we will take this merge only if we see a spike in user reports. Thank you.

The NextAction date has arrived: 2018-06-01

The fix is landed in 69.0.3447.0. I tested the 69.0.3447.2 on surface and it fixed.

Results for me:

Fixed:
Scrolling out of the 1000x1000 pixel zone
Scroll locking sometimes

Still with issues:
Right context menu still appearing from time to time while stopping it with two fingers, but I just found out that the same happens with Edge and the start menu list, so if might have something to do with the Microsoft implementation of the API.

Nice work :D

Thank you for testing. The right context menu is another issue from driver we don't know if MS would fix it.

 Issue 848656  has been merged into this issue.

chaopeng@, how safe is the change listed at #20 to merge to M67? So far we got 3 reports:  Issue 847611 ,  Issue 848331 ,  Issue 848656 .

I think it is safe to merge.

The CL in #22 is not fully safe for merge to stable because it is related to Windows API. We will turn off the feature if we seeing more reports in M67. 

Your change meets the bar and is auto-approved for M68. Please go ahead and merge the CL to branch 3440 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit fb6d5266cc47303c9d2648c870d08ab44e3689ef
Author: chaopeng <chaopeng@chromium.org>
Date: Fri Jun 01 23:15:39 2018

Fix snap fling by tap and unable to scroll for new page on Windows touchpad

The user reported 2 issues in this issue:

1. should stop fling when user tap on touchpad when fling
2. not able to scroll when user click on link to load a slow page then scroll

The first issue is caused by we don't setup the real window size for viewport.
The second issue is caused by we don't stop the viewport before activate
or deactivate the window that may turns the direct manipulation to a unknown
state and stop sending events to chrome.

Bug:  847611 
Change-Id: I646caf9aa70460741cedc1fea7804d8afe14d437
Reviewed-on: https://chromium-review.googlesource.com/1079460
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#563247}(cherry picked from commit 1c01a8d4e41312e1a7c0c7d7e67d6d65f8d86f1a)
Reviewed-on: https://chromium-review.googlesource.com/1083793
Reviewed-by: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#109}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/fb6d5266cc47303c9d2648c870d08ab44e3689ef/content/browser/renderer_host/legacy_render_widget_host_win.cc
[modify] https://crrev.com/fb6d5266cc47303c9d2648c870d08ab44e3689ef/ui/base/win/direct_manipulation.cc
[modify] https://crrev.com/fb6d5266cc47303c9d2648c870d08ab44e3689ef/ui/base/win/direct_manipulation.h

chaopeng@, thanks for merging my issue, I wasn't aware that this one fixes both momentum scroll as well as (as I now realized reading more carefully through comments) scrolling outside the 1000x1000 area. Nice to know the workaround exists as well until the change is available in stable channel.

Sorry for a duplicate.

Since this issue affect almost all touchpad user, we turn off the touchpad feature in M67.

Unable to reproduce the issue on hp laptop with precision touchpad using build without fix.
As per comment #7, it seems to be reproducible on a Dell laptop with precision touchpad and we don't have that particular device to test the issue.
Hence, requesting someone who are facing this issue for help in verification on latest canary.
The latest chrome builds can be downloaded from the below URL:
https://www.chromium.org/getting-involved/dev-channel

Thanks...!!

Hi krajshree, to reproduce this issue, you need to move mouse cursor to right bottom out of (1000, 1000) screen pixel, if you are using high DPI screen right bottom should be enough. Then scroll, lift finger then tap. You will see the tap does not stop the fling.

 Issue 853524  has been merged into this issue.

This issue is back again on Chrome 68.0.3440.75!

Hi landry.maxime, Which issue your seeing in M68? Please provide reproduce steps. Thank you.