It seems, that I am on an Experiment. I disabled all scrolling related flags one after one. Disabling chrome://flags/#disable-threaded-scrolling fixes the issue.

If you need more information, please let me know.

A bisect probably can't help here, because I am probably on an Experiment :-(

(I tried it in latest Chromium Snapshots, but I can not reproduce it there.)

As mentioned in c#2, in Canary disabling chrome://flags/#disable-threaded-scrolling fixes the problem.

Thank you in advance.

I can reproduce this on Mac only; Windows and Linux seem fine.

The disable-threaded-scrolling flag is ancient (introduced in 2014), and as far as I can tell we don't have any active experiments with it. So I don't think that's the cause.

We did do some CSS changes on the NTP in Chrome 61 which might be related, see bug 734038. In particular, we added a :hover style on the fakebox (which adds a box-shadow). I don't see why that would impact scrolling though. Also interesting: The local NTP (chrome-search://local-ntp/local-ntp.html) has the exact same :hover effect, but it doesn't show the choppy scrolling.

treib@ Thanks for your feedback. Just an additional note: I can also reproduce it at https://www.google.de/ with latest Canary. 

Indeed, I can reproduce it on google.com too. That means it's probably triggered by some server-side piece that's common between the Google homepage and the remote NTP. (Though ultimately, it's still a bug in Chrome of course.)

Given that per #4 it's likely *not* due to an experiment, could we get a bisect?

Adding some Blink folks, since Blink>Scroll doesn't have dedicated owners. Can you help route/triage this? Thanks!

Able to reproduce the issue on mac os 10.12.6 using chrome M63 #63.0.3205.0 .

This is a regression issue broken in M62 and seen only in mac os (Non-Retina).

Using the per-revision bisect providing the bisect results,
Good build: 62.0.3197.0 (Revision: 497604).
Bad build: 62.0.3198.0  (Revision: 497674).

You are probably looking for a change made after 497615 (known good), but no later than 497616 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.
 
 https://chromium.googlesource.com/chromium/src/+log/9b8fb34db903643b759635086dcf0da90b1e3082..668749693c0abc7f00871a2abea73628e6aa0332

From the CL above, assigning the issue to the concern owner 

@Steve Kobes - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Reviewed-on: https://chromium-review.googlesource.com/634512

Thanks!

+ReleaseBlock, since this is a regression.

My change is definitely not related (it only affects test code).

I can repro on Mac Canary.  I think it's related to the transition animation that removes the drop shadow highlight from the search box on mouseout.  On stable (where the bug doesn't repro), the search box has a much more subtle highlight without a transition animation.

Routing to estade from ntp/OWNERS to verify.  (Note, if this is indeed caused by a change to NTP styling, it may be worth filing a separate bug for Blink to handle the animation better.)

I haven't worked on NTP for many years. Hopefully the components labels will bring this to the correct person's attention, for now I'll pass off to tkent@ because it's probably worth addressing at the Blink level.

"Dispatch mouse transition events after layout" might affect this issue.

Re #11: I have verified that Chrome 61 (which already has the new CSS), is not affected, so this is not caused by the new CSS alone.

Attached is a trace of the issue. I wonder if we have a scheduling issue here. The trace shows the NTP is backgrounded but it isn't (is that actually correct?) and the main frame is actually delayed yet the CPU is actually idle.

altimin@ can you take a look?

Deleted: trace_backgrounded_ntp.json.gz 2.8 MB

trace_backgrounded_ntp.json.gz 2.8 MB Download

Sami and I have looked into that and it seems that tree activation takes 300ms to activate and it's not obvious why. Main thread is blocked by ProxyMain::BeginMainFrame::commit waiting for something, but compositor thread and tile workers don't seem busy.

So I don't think that it is a scheduling issue and let's have compositor folks to look into that.

ccameron@ can you look at this from a compositing point of view?

I can't reproduce it any longer in today's Canary 63.0.3208.0.

Is this also fixed for you all?

I can't seem to repro it. Change log is here:
https://chromium.googlesource.com/chromium/src/+log/63.0.3207.0..63.0.3208.0?pretty=fuller&n=10000

because I did repro it on 63.0.3207.0

flackr@ could https://chromium-review.googlesource.com/c/chromium/src/+/591913 be the fix?

Closing as not reproducible anymore.