Unable to reproduce the issue on chrome reported version# 67.0.3396.87 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://picclick.com/Optical-Fiber-Optic-Inspection-Scope-400x-Fiber-Microscope125-250mm-252118428566.html
2) Started scrolling down the page, didn't observed any slowness or freezing of the browser

@Reporter: Please find the attached screencast for your reference and provide your feedback on it, try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

Thanks!

Deleted: 854451.mp4 9.3 MB

	854451.mp4 9.3 MB View Download

Simplified repro built from the page in #0:

1. unpack the attached zip and open 1.html
2. wait for the page to load ~15-30 seconds
3. click in any empty space between pictures
4. press and hold the "down arrow" key on your keyboard

Expected: smooth scrolling of the page
Observed: scrolling freezes regularly

====================================

Bisect info: 500358 (good) - 500362 (bad)
https://chromium.googlesource.com/chromium/src/+log/a19f25e6..9cc23fc9?pretty=fuller
Suspecting r500360 = 05d35a67a192ea687683dfcbe66ade866cbfcc98 = https://crrev.com/c/655129 by flackr@chromium.org
"Reland "Fix effective touch actions to come from hit test rects.""
Landed in 63.0.3209.0

====================================

The trace (attached below) shows ScrollingCoordinator::setTouchEventTargetRects as the primary CPU consumer
Same is observed in Canary.

Deleted: test-page.zip 433 KB

test-page.zip 433 KB Download

Deleted: trace_r500366.json.gz 6.2 MB

trace_r500366.json.gz 6.2 MB Download

@ Comment 2

I have deinstalled and deleted all (hidden) folders and files from Chromium and reinstalled the Portable Version:
64bit • No sync • No WebRTC • No Widevine • 67.0.3396.87 (550428) • Wednesday, 13 Jun 2018

Without any extensions or apps.

I experience still the exact same problem when visiting that site and start scrolling down with the mouse wheel.

I have a Laptop Dell Studio 1537, Windows 7 64bit, 4GB Ram, Intel Core 2 Duo T6400 and ATI Mobility Radeon HD 3450, Resolution 1280x800

Windows and all Drivers are up-to-date.

@ Comment 3 

I have downloaded your test-page.zip and followed your steps from 1 - 4
I experience the exact same issue: regularly scrolling freezes. 

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 have tested the issue with a different Notebook which is just 1 year old:

Acer Aspire E5-774G, Windows 10 64bit, 8GB Ram, Intel Core i5-7200U 7th Gen and Intel HD Graphics 620, Resolution 1600x900

Windows and all Drivers are up-to-date, too.

I've installed a fresh and the latest Portable Version without any extentions/apps:
64bit • No sync • No WebRTC • No Widevine • 67.0.3396.87 (550428) • Wednesday, 13 Jun 2018

What happens:
The more i scroll down in that mentioned site, the more unresponsive, less performant, slower and "freezy" the scrolling becomes.

Then i've installed Firefox 60.0.2 
The scrolling is highly responsive, performant and smooth.
No issues at all.

I can reproduce on fresh Chromium Version 66.0.3359.117 (Developer Build) built on Debian 9.4, running on Debian 9.4 (64-bit)

flackr@, is your patch expected to have a negative impact on lifecycle perf?

Note, we plan to address the underlying issue here in issue 125223 which is to move keyboard scrolling off main thread.

Not just via the keyboard, it also freezes periodically for 
1) the scrollbar down button, 
2) the mouse wheel, 
3) the mouse wheel autoscroll feature. 

Do all of these methods simply invoke the same keyboard scrolling code internally for this type of scrolling?

No, but the issue is likely that we're blocking the scroll on the main thread which can be busy - hence the pause. Keyboard and scrollbar scrolls will always be main thread blocked. Wheel and autoscroll may or may not be depending on page content and monitor density. 

If you could capture and attach a performance trace when the scroll performance is bad it would be helpful for triage.

There's a trace in comment #3.

I have noticed one general huge issue since i'm now browsing with the latest Firefox and Chromium:

when Firefox starts loading a website and hasn't even finished, i can scroll nearly instantly and without delays.
It feels super performant and super responsive.

But when Chromium is loading a website, it takes time when the first scroll will be "answered". The scrolling lags and is very unresponsive.

Here for example:
http://www.mediamarkt.de

Tested with my Laptop:
Dell Studio 1537, Windows 7 64bit, 4GB Ram, Intel Core 2 Duo T6400 and ATI Mobility Radeon HD 3450, Resolution 1280x800

When i disable both "Auto-Scroll" and "Smooth Scrolling" in Firefox, the overall scrolling experience gets to another level which is just superb.

I wish that Chromium someday catches up and could do the same performance.

Deleted: Firefox new settings.png 121 KB

	Firefox new settings.png 121 KB View Download

Chrome has always been immediately responsive until r500360 landed in Chrome 63.

Re #8, my patch shouldn't have a significant difference to performance. It fixed some correctness issues (need to report if a contained descendant has a different touch action) but even removing this that site still seems to get the same large number of touch action rects.  Issue 718271  is similar and we should probably look at this as a broad class of issues with touch rect generation.

It seems like there's very few layers so we probably should have hit the kMaxRectsPerLayer limit of 100, but perhaps because after my patch we're now tracking each touch action separately we no longer hit 100 in any particular list. Maybe it's worth having a lower limit and/or counting the total number of regions and merging other touch actions.

pdr is working on a new path for generating these rects which should significantly reduce the generation time, this seems like an excellent site to benchmark for  issue 853824 .

I've updated to the newest Chromium 64bit • No sync • No WebRTC • No Widevine • 67.0.3396.99 (550428) • Tuesday, 26 Jun 2018

The initial scrolling problem still exists while Firefox 61.0 (64-Bit) shows no failures/weaknesses at all.

BTW, here is another website, where i can scroll instantly with Firefox while the site is loading:

https://en.chessbase.com/post/grand-chess-tour-2018-paris-blitz-2

But Chromium has huge scrolling freezes/problems, while this site is loading.

I'm really disappointed.

Today i have installed the newest Chromium version Sync • WebRTC • Widevine • 68.0.3440.75 (561733) • Thursday, 26 Jul 2018 

But the scrolling still sucks.

Looks like this serious BUG hasn't been fixed at all.

Can you verify whether this is the same as  issue 800522 ? i.e. that touch rect generation is where we're spending the time?

flackr@, FWIW in that bug TE claimed they observed the behavior since M50 but my bisect here shows M63.

Guys, i have solved the problem.

For normal browsing (80% of the time) I'm using Firefox now.
For media/audio I'm using Chromium.

Maybe the scrolling bug will be fixed with Chromium version 100   lol

 alphaomegajesusisgod@: please run canary channel with --enable-blink-features=PaintTouchActionRects, you will find it much smoother. This feature will be shipped soon.

PaintTouchActionRects is shipped and will be available on tmr's canary channel.

Re-open because we revert ship of PaintTouchActionRects.

PaintTouchActionRects has been shipped.

I've upgraded to Chromium 71.0.3578.80 (599034) • Wednesday, 5 Dec 2018 64-bit
and don't see any improvements at all.
The BUG is not fixed, the scrolling still sucks as it was before.

PaintTouchActionRects is shipped in Chrome 72, not 71.
Using the test page in comment 3 I no longer see the lags in Chrome Canary here.

OK, for testing purposes i've installed the Portable Chromium 
Development build (official repository) 73.0.3633.0 (614274) • Wednesday, 5 Dec 2018 64-bit 

The scrolling in the original post is still very bad, unresponsive and freezy the more is scroll down.
URL: https://picclick.com/Optical-Fiber-Optic-Inspection-Scope-400x-Fiber-Microscope125-250mm-252118428566.html

Chromium doesn't even remotely come close to how Firefox performs.

I will stay with FF, the bug hasn't been fix at all in my eyes.

alphaomegajesusisgod@gmail.com: could you please grab a tracing.

Open chrome,
1. go to chrome://tracing, and select "Record" on the top left corner.
2. select "Rendering", and hit "Record".
3. Then go to the test page and start scrolling, after 10 seconds or so go back to the tracing page, and hit stop. 
4. Hit "Save" on the top left corner of the tracing page.

This should save a tracing, could you upload it here. I am very curious what is causing the problem. I tried locally on a window 10 with chrome 73 and it is smooth.

Of course i can do it, here we go, done with: Portable Chromium
Development build (official repository) 73.0.3633.0 (614336) • Thursday, 6 Dec 2018 64-bit

Hardware accel on/off doesn't make any difference.
The recording was done with standard hardware accel. enabled
File: trace_stutter_lagging_minifreezes.json.gz

Deleted: trace_stutter_lagging_minifreezes.json.gz 9.2 MB

trace_stutter_lagging_minifreezes.json.gz 9.2 MB Download

Oh, I was being really dumb. I am really sorry about that, could you select "Input Latency" instead of "Rendering", when do you the tracing, and please upload your trace again.

Sorry about that.

It's best to select all the "default" categories (the left box). Some important bits are scattered throughout and as long as your recording isn't too long it shouldn't be an issue.

Alright: only recorded the "Input Latency":

File: trace_Input Latency.json.gz

Deleted: trace_Input Latency.json.gz 4.1 MB

trace_Input Latency.json.gz 4.1 MB Download

And here a recording with ALL default categories (the left box):

File: trace_all_categories.json.gz

Deleted: trace_all_categories.json.gz 5.9 MB

trace_all_categories.json.gz 5.9 MB Download

Looked at the trace, and the root cause isn't the same as described in this bug. I will file another bug and attach the trace there.

Basically here is an accurate description between Firefox and Chromium:

FF: as soon and no matter how "fast" i hit the mousewheel, up or down, FF scrolls instantly, the response time is like 0ms

Chromium: so laggy and stuttering / mini freezes, response time many ms to seconds