+erikchen, TL for memory-desktop. 
AFAIK, we have scrolling cases both on android and desktop (specifically all the browsing stories in system_health.memory_mobile and system_health.memory_desktop) , however:
1. right now memory perf alerts are turned on only on Android (which seems unaffected by the issue). This is mostly due to staffing/bandiwdth, and is something on track by chrome-memory-desktop. So there is a chance that the regression is showing in the dashboard (any idea in which cr-commit-position it was introduced?)
2. Not sure about the "wheel" scrolling. I think that the way scrolling is implemented today is via JS scrollTo and not synthesizing mouse wheels, but I might be terribly wrong on this point (+nednguyen / +perezju who know way more than me here).

After bisecting I found the regression was introduced by http://crrev.com/417132 (not quite as old as I thought).

JS scrollTo won't repro this, it requires input events hitting the compositor.

skobes: Thanks for bisecting. This wasn't visible at all by system health benchmarks. We get run-to-run noise of ~200KB, so a couple of bytes isn't going to be visible.

Deleted: Screen Shot 2017-03-21 at 3.29.35 PM.png 853 KB

	Screen Shot 2017-03-21 at 3.29.35 PM.png 853 KB View Download

Scroll simulation in Telemetry is done through https://cs.chromium.org/chromium/src/content/renderer/gpu/gpu_benchmarking_extension.cc?rcl=a0a9840a39b61caca179486dcf20927fe99ad4a6&l=684

I am not sure whether this is realistic enough to reproduce  Issue 701025  though. 
+Erik: maybe we can make a stressed scroll test in trivial page to see if it can detect the issue?

Assuming we leak 16 bytes per scroll, we'd need 6000 scrolls to get a 100KB leak. I don't know how cc handles scrolls [e.g. do we need separate scroll?]. Maybe this is worth doing, but the test would take a while to run.

This seems like a potentially good case for extending the cc MemoryDumpProvider. What is the object that is leaking in this case?

> What is the object that is leaking in this case?

AnimationPlayer::animations_ is a std::vector<std::unique_ptr<Animation>>.  Each scroll added a cc::Animation object to the vector, and they never got removed when they finished.

Would it be possible to write a pathological page that catches this leak? How long would we have to run the page to generate a sizable leak? (100kB)

Maybe this is silly but on the metric side, I wonder whether we can track objects count as a another memory related metric? That may help with detecting leaking of objects of small size, I think

The objects are 120 bytes and the leak is rate limited by the animation time (~150 ms).  So pathologically we could leak up to 800 bytes per second or 100 KB in just over 2 minutes.

If this is still valid, we should find an owner.

This regression has been open for half a year. It's not very actionable and the regression has been in all Chrome user's hands for months.

Just to clarify: I fixed the regression before I filed this bug.  The fix is r457443.  This bug was to see if we could improve our testing.