Manual regression range:
Good Build:  55.0.2853.0 
Bad Build:   55.0.2855.0 

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/214983ef4fda427d96e275273f53c1c982522635..37998d9dae51da52b1896aa9bd780b16600552c6?pretty=fuller&n=10000

Suspecting:417141 ?
Kindly help to re-assign, if your changes are not cause for this issue. 

Note: Issue not seen on Mac & Linux OS.

Deleted: Actual_Scroll.mp4 540 KB

	Actual_Scroll.mp4 540 KB View Download

Deleted: Expected_Scroll.mp4 2.2 MB

	Expected_Scroll.mp4 2.2 MB View Download

Adding release block label, please undo if not the case.

There is also a pdfium roll in the changelog:

https://chromium.googlesource.com/chromium/src/+/7e97e0f27effc208f15a6ed2952f648c18636392

It would surprise me if my change caused for Windows-only.

I am trying to build on Windows but hitting build errors currently. Will update.

+ kenrb@ just because he's working on mouse event routing stuff at present.

I can repro at ToT with public Chromium build on my Win7 machine. Exploring narrow bisect range from above.

The issue turns out to be sporadic and tricky to repro. Sometimes I think I'm testing a build and it's good, and then later I'm able to repro on that build. As if it depends on where you click, or what state the mini-PDF view (or its animated black bar at top) is in when you mouse in/out or move the scroll wheel.

Bisecting builds again steered me to a different pdium roll:

https://chromium.googlesource.com/chromium/src/+/b593fc7f40d125e327700218e1f0f4ea51721a08

with only one change:

https://codereview.chromium.org/2307243002/
Clean up redundant code in PDF_ENABLE_XFA guards in FFLCommon.

I'm near certain I saw the issue with this build @ r416448 but just now I tried to reproduce again and I couldn't.

vkupte@ are you able to reproduce more reliably, can you try coming up with 100% definitive repro steps? Are you experiencing the sporadic flakiness that I describe?

On Win7, for future reference, unless someone knows an easier way to launch a specific build for testing:

% python .\tools\bisect-builds.py -g 416447 -b 416448 -a win --verify-range --use-local-cache -- http://www.pdfobject.com

I definitely just repro'd with a local build at r416448. I had to click in and out back and forth maybe 6 times, scrolling up and down throughout, before the main page scroll hung.

Trying now with r416447. Couldn't repro with this build no matter what I tried.

Went back to r416448 and couldn't repro. Quit, relaunched, and was able to repro after three or four clicks.

This tentatively confirms the bisect notes I have in #7 above, and that the pdfium roll is cause.

Passing ownership to dsinclair@ to investigate further or otherwise route as it looks pdfium related. If tester is able to produce more definitive repro steps would help with debugging.

I can't repro this issue at all. Lei, can you take a look as you reviewed the CL this is referring too?

So this is definitely Windows only?

I really don't think https://pdfium.googlesource.com/pdfium/+/738766eefaf14fabb168f1f5a5c987f8e7049cab can cause this:
(a) It should not change any existing behavior because it's a clean up CL.
(b) It only affects rendering flags, which cannot affect scrolling outside of the PDF.

I tried to repro this on Linux with a build from earlier today, and one time I hit this crash:

[1:3:0919/195753:FATAL:scroll_offset_animations_impl.cc(71)] Check failed: element_id == scroll_offset_animation_player_->element_id() ((1, 1) vs. (2, 1))
#0 0x7fb851a9e88e base::debug::StackTrace::StackTrace()
#1 0x7fb851b0becf logging::LogMessage::~LogMessage()
#2 0x7fb8499333aa cc::ScrollOffsetAnimationsImpl::ScrollAnimationUpdateTarget()
#3 0x7fb8498f0031 cc::AnimationHost::ImplOnlyScrollAnimationUpdateTarget()
#4 0x7fb849bfe12a cc::LayerTreeHostImpl::ScrollAnimationUpdateTarget()
#5 0x7fb849bfe796 cc::LayerTreeHostImpl::ScrollAnimated()
#6 0x7fb84b9e58dd ui::InputHandlerProxy::HandleGestureScrollUpdate()
#7 0x7fb84b9e3ce3 ui::InputHandlerProxy::HandleInputEvent()
#8 0x7fb84b9e31f9 ui::InputHandlerProxy::HandleInputEventWithLatencyInfo()
#9 0x7fb84d3dd376 content::InputHandlerManager::HandleInputEvent()

Not sure if that's related.

/cc ymalik@ for FATAL crash in "scroll_offset_animations_impl.cc". Can this crash be at all related?

Still able to repro this issue on Latest Canary Version - 55.0.2874.0 

Tested on Windows 7

I think this is related to scroll bubbling. To revise the repro instructions:

1) Using the mouse scroll wheel, scroll the PDF as much as you like *without* scrolling to the top/bottom limits of the PDF ... then moving the mouse outside the PDF and scrolling should work.

2) As soon as the PDF is scrolled until it hits its limit, then it will no longer be possible to scroll the outer frame.

I've notice on Mac that mouse wheel scrolling via trackpad fails to correctly generate synthetic scroll begin/end pairs, and this confuses the overscroll controller ... perhaps this is related? (https://bugs.chromium.org/p/chromium/issues/detail?id=628742)

I can also reproduce this behaviour on Linux using the instructions in Comment #14. It seems likely It may also reproduce on CrOS as well then, though I haven't confirmed this yet.

I can repro this on Linux using the instructions in comment #14.

I am not sure if the crash in comment 11 is related, but I verified that this works with smooth scrolling disabled. 

Looking into this further...

So this seems to be related to scroll bubbling mechanism that works for BrowserPluginGuest/RenderwidgetHost not understanding correctly about trackpad scrolling.

Currently we have mouse wheels being *directly* target to the subframe, the synthetic scroll gestures being created by that renderer's RenderWidgetHost, and then the Gestures are send directly to the guest, and get acked back for bubbling. At present this works correctly for scrolls that are initiated by touch events, but not for wheel events.

There may be multiple problems here.

I suspect that the issue described in comment 14 has to do with r417132.

I reverted it (and changes that depend on it) locally and it fixed the problem described in comment 14.

I can also repro the crash in  issue 11 , but don't think that's related.

Edit: comment 18, reverting loyso's patch (r417132) doesn't really fix the problem, it just makes it happen less frequently

 Issue 647618  has been merged into this issue.

ymalik@ I don't quite understand your comment in #20: I've observed via my repro instructions in 14 that I can reproduce it 100% of the time, without the "repeat 2-3 times" type of non-deterministic instructions in the original report.

Are you saying that attempting to scroll past the PDF's extent, either top or bottom, and then trying to scroll the main frame works sometimes but not always after the reverts?

@wjmacleanm that is correct, after reverting patch r417132, the repro steps in comment 14 don't reproduce it 100% of the time, but it still happens once in a while. This indicates that r417132 is not the root cause of the issue, but probably makes it happen more often.

@wjmaclean can you verify that this fixes the repro in comment 14? https://codereview.chromium.org/2391643002/

Explanation in CL description.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eebaccca7bd4bc2f1a9fb9eaf8dcbc9c0377064d

commit eebaccca7bd4bc2f1a9fb9eaf8dcbc9c0377064d
Author: ymalik <ymalik@chromium.org>
Date: Tue Oct 04 20:01:02 2016

BrowserPluginGuest::ResendEventToEmbedder should keep the same deltaUnits

When a nested scroller is at its scroll bounds InputHandlerProxy gets another
set of synthetic GestureScrollBegin/Update/End to scroll the parent scroller.

Before this CL, deltaUnits was not copied in GestureScrollBegin but was copied in
GestureScrollUpdate. As a result, InputHandlerProxy would expect an instant scroll
after GestureScrollBegin, but perform a smooth scroll in GestureScrollUpdate.

BUG= 647205 

Review-Url: https://codereview.chromium.org/2391643002
Cr-Commit-Position: refs/heads/master@{#422894}

[modify] https://crrev.com/eebaccca7bd4bc2f1a9fb9eaf8dcbc9c0377064d/content/browser/renderer_host/render_widget_host_impl.cc

Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.6 using chrome version 55.0.2882.0 as per the steps mentioned in comment #0.Able to scroll the pdf page using middle mouse wheel without any issues.
Please find the attached screen cast for the same.

Adding TE-Verified label.

Thanks,

Deleted: 647205.mp4 6.1 MB

	647205.mp4 6.1 MB View Download

[Auto-generated comment by a script] We noticed that this issue is targeted for M-55; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-55 label, otherwise remove Merge-TBD label. Thanks.

CL landed at #25 landed before M55 branch. No M55 merge is needed.