confirmed

Yes, I can confirm this behavior as well, it's clearly a regression.
Based on our research this bug first appeared in NW.js 0.19.2 based on Chromium 55.0.2883.87, probably related to this update?
https://chromereleases.googleblog.com/2016/12/stable-channel-update-for-chrome-os.html
It's strange that we cannot reproduce this behavior in latest Chrome, when using Web App, only in Chromium and NW.js 0.19.2+ which is based on Chromium.

Unable to test this on Chromium as facing issue with the touchpad scrolling on Windows 10 Dell touchscreen laptop.

Looping bokan@ from  Issue 505516  and labelling the bug accordingly for more inputs on this.

I can repro - this is specific to <webview>. A simple way to compare is to inspect the attached app and navigate it to https://en.wikipedia.org/wiki/Cat and compare with the regular browser. Scrolling behavior is clearly wonky in WebView - almost as if we double up scrolls or something. When I fling a couple of times I see the velocity start fast, slow down, but then speed up again.

Since this is <webview> - I'd guess it's related to OOPIF issues. James, could you please triage?

Confirmed by bisect:

https://chromium.googlesource.com/chromium/src/+log/04e7784ab645b42a30304cf515efd694dddc2ba0..a41e7dd53d4bc9f268939d10a02c24302cef8020

which contains

9729c20 Change Isolate Extensions to be off by default. by nasko · 3 months ago

ping, could someone take a look at this?

If this is <webview>, then it's not (currently) oopif related.

Let me see which flags really apply.

I did a more-extensive manual bisect on this, and the culprit CL seems to be:

https://codereview.chromium.org/2324803005

which landed at r417946. The effect is only seen when all site-isolation and webview-oopif flags are off, which unfortunately at this time was not possible since --isolate-extensions was on without any way to turn it off, hence why build-bisect failed (it pointed to the CL where --isolate-extensions was made off by default, but it will soon be re-enabled).

** To reproduce my manual bisect, it is necessary to force SiteIsolationPolicy::AreCrossProcessFramesPossible() to return false, which in turn triggers the pathway which routes mousewheels via the embedder.

While debugging this I noticed that touchpad-generate mousewheels being sent to the guest/child after passing through the embedder are causing resent mousewheels back to the embedder. I wouldn't expect this, since presumably the guest doesn't consume them, and they therefore cause GestureScroll events (which will always go directly to the guest). The wheels resent to the embedder are also marked as not-handled (see BrowserPlugin::handleInputEvent()), in which case I suspect they generate a further stream of GestureScrolls, which will also directly target to the guest ... this I suspect is the root cause of the "furious" scrolls (i.e. too-much scrolling).

Fixing this may be as simple as just preventing touch-pad generated wheels from creating event resends.

I just did a quick check, and not re-sending the touchpad mouse wheels does indeed solve the problem. But there's no (obvious to me) way to differentiate between real-wheels and touchpad-wheels, so that needs to be figured out (though perhaps we shouldn't be sending *any* wheels?).

Likely the we shouldn't be coalescing when the resender id doesn't match.

See: https://cs.chromium.org/chromium/src/ui/events/blink/blink_event_util.cc?l=258

Removing Needs-Triage-M57 label as its already worked upon and TE team can't triage it further.

I've added a check where I thought the problem might be but I'm unable to reproduce the issue you indicate. Will need to loop back with james about what hardware this is occurring on (I've tried a wacom external touchpad on windows, apple touchpad with linux).

I was using thinkpad t460p

I was using Linux and an Apple touchpad.

You'll need to manually disable event routing ... just turning off --isolate-extensions isn't enough anymore. Instead you need to modify AreCrossProcessFramesPossible() to always return false in order to reproduce.

https://cs.chromium.org/chromium/src/content/common/site_isolation_policy.cc?rcl=f5e1caa227f7d458748a92f45938811e87c1f43b&l=26

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

commit b20bd7450c4a855003e366b6c3de9bf660092b54
Author: dtapuska <dtapuska@chromium.org>
Date: Thu Mar 02 18:01:25 2017

Make sure resent events that don't match ids are not coalesced.

Resent events with different ids could get coalesced together causing
a larger magnitude than originally intended. Only coalesce events
that have the same id.

BUG= 681353 

Review-Url: https://codereview.chromium.org/2723023005
Cr-Commit-Position: refs/heads/master@{#454304}

[modify] https://crrev.com/b20bd7450c4a855003e366b6c3de9bf660092b54/ui/events/blink/blink_event_util.cc
[modify] https://crrev.com/b20bd7450c4a855003e366b6c3de9bf660092b54/ui/events/blink/blink_event_util_unittest.cc

This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

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

Thank you for the fix.
 Seems like this issue exists on M55 and M56. We're very close to M57 stable launch (Stable RC cut for Desktop on Monday, 03/06) so we're ONLY taking critical merges in. Can this wait until M58?

It's probably not critical for M57, I had thought since it was low-risk it'd be ok. But I'll leave that call to you. 

Thank you wjmaclean@. Sorry, this will have to wait for M58 although it is low-risk change.