You are probably looking for a change made after 546635 (known good), but no later than 546636 (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/ed8f674f763a5eaba8c31d417cc13d7190127186..46259cc58e11f12ca3308b694c59a14b195fc703

Suspect: https://chromium.googlesource.com/chromium/src/+/46259cc58e11f12ca3308b694c59a14b195fc703

@sahel: 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.

With Autoscroll browser side fling, the renderer handles GSUs from autoscroll similar to GSUs from touchscreen and wheel scrollling.

If you try wheel/touchscreen scroll you will notice that the scroll bubbles to the parent once the pdf scroller hits its extent.

The root cause of the issue is that pdf is currently using BrowserPlugin instead of oopif, and BrowserPlugin doesn't support scroll latching.

I'll reduce the priority of this bug, since even though it is a recent regression in autscroll behavior, wheel and touchscreen scrolling has been always like this and once pdf switches to using oopif the scroll latching will work for all types of scrolling.

MimeHandlerViewGuest embeds another plugin inside (PDF PPAPI). I wonder if same problem exists there as well. If so, even with MimeHandlerViewGuest transitioning to using OOPIF this bug won't be resolved. But perhaps we could look into that "after" MimeHandlerViewGuest moved to using OOPIFs but that will won't be any time soon.

Had a chat with ekaramad@, we are hoping that crbug.com/659750 will be fixed by the end of Q3.
Since other kinds of scrolling has had this behavior for a while (touchscreen scrolling since M47 and wheel scrolling since M65), I think waiting till Q3 is fine.