This doesn't seem to happen in stable, so marking as a regression and a P1. Not sure if there is a Speed triage process I should be putting this into.

Here's a trace in an incognito window with ghostery enabled. Ghostery is process 66625.

Taking a look through the trace, there's a ton of JS running, but it's all in smallish chunks. Certainly nothing as long as 1 second. But Scheduler:pending_submit_frames does indeed show the 1fps-ness of it.

It's not at all clear to me what's going wrong.

Deleted: trace_huffpost-ghostery (1).json.gz 12.4 MB

trace_huffpost-ghostery (1).json.gz 12.4 MB Download

Hmm, checking as far back as 54.0.2840.98 the stuttering seems to still be there.

Sorry, I probably should have taken a video. It stutters on stable (even without ghostery), but it's not 1fps level of stutter. It's dramatically worse on canary for me.

Planning to do a DEV release today.Tagging as RBB, since we don't have an owner, but please try to get this resolved ASAP.

Unable to reproduce the issue on Mac 10.12.3 , Windows 7 & Linux Ubuntu 14.04 using chrome reported version-58.0.3019.0 & Canary-59.0.3033.0 as per the below steps:
1.Installed "Ghostery" extension
2.Navigatd to the below URl
 http://www.huffingtonpost.com/entry/george-w-bush-friendship-michelle-obama_us_58b87442e4b01fc1bde6e835?section=weird-news
3.Scrolled the page while loading
4.Observed FPS in Devtools while scrolling

Noticed FPS >10 & page loaded & scrolled smoothly without any issue.
Please find the attached screencast for reference & let us know if we miss anything to reproduce the issue.
Note:Tested on Mac Book Air & Retina also & observed the same behaviour.
Thank you!!

Deleted: 698556-Mac.mp4 10.3 MB

	698556-Mac.mp4 10.3 MB View Download

The main problem seems to be that the page has a potentially blocking wheel handler and the main thread is very busy. From the trace it also appears that we're not attempting to prioritize the wheel events for some reason. A trace with with the disabled-by-default renderer.scheduler category enabled would help in diagnosing why.

Also, not the root cause, but in one section of the trace there are about 5000 timers scheduled by ScrollAnimatorMac.mm in a span of 250ms.

Tagging as RBS,please resolve before M58 hits Stable.

Not sure I buy that this should be p1 and R-B... its important but there are a LOT of things that are important. Ojan are you sure we should be considering this release blocking? Its definitely something we should triage, but its got the right speed labels on it to get triaged eventually so...

I was only marking it as ReleaseBlock because it seems to be a huge regression. I worry that until we understand the regression we don't know if it's limited to huffpost.

If it were not a regression, then I think it would be P2/P3 and certainly not a release blocker.

Hmmm...now that I test again, it doesn't seem to be a regression. I can now repro on Chrome 56 stable. Sorry for the fire. So, removing the Release-Block.

That said, something is badly wrong here and probably warrants looking into soonish. I'd say at least understanding what's going wrong might be P1 worthy.

Here's another easier set of repro steps I encountered looking into issue 693054.

1. Load politico.com. Wait for it to finish loading.
2. Scroll down a bit and cmd+click 3+ links to articles. The more articles you open, the worse it is.
3. Try to scroll.

In a pure incognito window, you can easily scroll with some minimal jank. In an incognito window with ghostery enabled, there are a number of large janks where you can't scroll the page at all for >10 seconds. Once the background tabs have all loaded, then the page scrolls smoothly again.

I couldn't get a trace with renderer.scheduler category checked due to issue 700784. And trying to get a trace without it checked OOMs (I assume that's why it crashed anyways). I've now spent an hour trying to get a trace and am giving up. Hopefully someone else can succeed.

Have we reached out to ghostery at all?  (This bug's not restricted; any objections to doing so?)

No objections to reaching out to ghostery, but I feel we should start by understanding what's going wrong. I suspect it's more likely something we should fix on the Chrome end that effects multiple extensions than something truly ghostery specific.

As another data point, I don't see the scroll jank if I do this on Chrome 56 on ChromeOS, but I do see the same behavior trying to close the tabs while they're loading. Namely, they hit the 1 second timeout, which likely implies that the renderer main thread is too janked to respond to the close request from the browser.

This could be a symptom of the lag rather than the cause, but I noice there are ~7000 main thread tasks from startScrollbarPaintTimer in rapid succession.

Title TaskQueueManager::ProcessTaskFromWorkQueue
src_file	
  "../../third_party/WebKit/Source/platform/mac/ScrollAnimatorMac.mm"
src_func
  "startScrollbarPaintTimer"

In a quick test on my Linux Desktop, we're spending 150ms during pageload in dispatchOnMessage (https://cs.chromium.org/chromium/src/extensions/renderer/resources/messaging.js?rcl=b564548ad17fbddb292f135951aefcbde141e400&l=315). There's a bunch of time in other extensions related places as well.

See the CPU profile I've attached (taken with devtools CPU profiling tools). Ghostery is the only extension installed.

The total amount of time spent doing extension related things is crazy, though it isn't clear to me how much of it is overhead, and how much is Ghostery doing crazy things.

Deleted: huffington-with-ghostery.cpuprofile 5.2 MB

huffington-with-ghostery.cpuprofile 5.2 MB Download

bokan@ can you comment on the ~7000 tasks to animate the scrollers

ojan@ - I tried to bisect this, but wasn't able to reproduce locally (either through the huffingtonpost link in #0 or through the politco repro in #11).  If you're able to consistently repro, can you run a quick bisect and see if anything crops up?

tdresser@ #17 - messaging in extensions is a known paint point.  The TL;DR is that it's almost always the extension doing crazy things, but the API makes it easy enough to do those crazy things and we don't do a good enough job a) discouraging it and b) making it clear what the cost of it is (and probably c), how to do it right).  That said, I don't think much has changed there lately that would have a negative performance impact, and the 150ms doesn't seem like it would quite account for the 30fps -> <1fps drop ojan@'s describing.

Yah, I don't think its the cause of the badness but its certainly exasperating the issue. ScrollAnimatorMac's scrollbarPaintTimer has been known to fall into degenerate cases like this, I've been meaning to replace it with something more sane. I'm tracking that in issue 669945 but haven't found the time to look into it yet. I'll see if I can repro it more reliably with these steps when I get back to a Mac.

I still can't reproduce this on ChromeOS, but I just had someone else verify that they can reproduce it on their MacbookPro on Chrome 56. So, this might be mac specific.

To update, Ojan and I tried to repro on my Mac Pro desktop, and couldn't.  So perhaps this is laptop specific in some way (touchpad?), or perhaps there's something else going on.

What are the specifics of the machines where it can be reproduced vs where it can't? Retina display? Scrollbar mode (overlay, always on)?

The MacbookPros where it repros are high-dpi and default scrollbar mode (so, overlay?).

It didn't reproduce on Devlin's desktop MacPro. I assume his monitor was lowdpi. It also didn't reproduce on my Pixel 1, which I think is hidpi since window.devicePixelRatio returns 2.2? Also default scrollbars, which I think is overlay on chromeos?

So, I don't see a pattern there. Not sure what other specifics could matter here.  Maybe GPU rasterization isn't enabled for the MacPro and Pixel? chrome:gpu says the following for the rasterization row on my pixel: Rasterization: Software only. Hardware acceleration disabled.

Devlin, what does the rasterization row on your MacPro say in chrome:gpu?

Actually, force enabling GPU raster doesn't make it repro on my Pixel 1.

I couldn't repro it either on a MacPro with a loDPI monitor (but tried with --enable-prefer-compositing-to-lcd-text which is the difference) and using overlay scrollbars. 

Ojan, was the repro reliable on your machine or was it occasional?

Ok, I managed to reproduce the issue on a new MBP. Plugging in a lowDPI monitor and moving Chrome into it makes scrolling during load noticeably smoother so it has something to do with DPI

@27 - "Hardware Accelerated"

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Hardware accelerated
Rasterization: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

The trace in comment #1 shows that there's a long time between the cc::Display's swap buffers and the corresponding ack. It looks like part of the problem could involve either the GPU or Browser process and it's swap interface to the OS when the Ghostery plugin is enabled.

Bokan: Is there still badness when you forced impl-side scrolling with "passive event listener override"?

Chris: Have you seen swap acks take a really long time to return before?

Didn't try with the override but it was on dtapuska@'s laptop, perhaps he can give it a try.

Re #32, not really -- most GPU starvation issues are cross-platform

Re #32. No, I haven't seen swap acks take more than a few vsyncs on Mac.

Gentle ping .. to get an update on this issue , as it is marked as release block stable.

Thanks!

This isn't owned and we don't have a solid group of Performance-Responsiveness owners, so dropping the RBS label.

Something we could do here from the scheduler's point of view is to remove the 10s grace period before throttling a backgrounded tab. Currently the blocker for this is that 1) the renderer doesn't have accurate visibility information at startup and 2) we'll still need something like a wake-up budget to deal with some special cases like clicking on an extension button to open a pop-up.

Ojan and I took another look last week.  In order to repro, ghostery settings have to be set to block nothing.  With this, it looks like it will repro on all mac platforms, though the effects are much more noticeable on a MacBook than on a MacPro (just due to machine beefiness).

It's still unclear what exactly the root issue is here, between Chrome, Ghostery, Ads, and some combination of the above.  Ghostery is certainly doing a ton of work, but the fact that it doesn't repro with "block everything" makes me think that it's not just Ghostery and some combination of Ghostery + ads on the page.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Frankly speaking, we don't have a bandwidth to look into this in a foreseeable future.