Tested the issue on Mac OS 10.12.6, windows 7  using M60 #60.0.3112.113 and M62 #62.0.3202.0 and observed as attached in screencast.

@screenshaderapp-- Could you please check attached screencast and confirm us if this is the issue you are talking about or provide us a screencast for better understanding.and also provide us the OS details in which you are seeing the issue.

Thanks!

Deleted: 761105.mp4 5.4 MB

	761105.mp4 5.4 MB View Download

@hdodda Yes that is the buggy behaviour I observed.  I tested it on Windows and Chrome OS with similar results.  This bug appears to affect all current versions of chrome on all OS though further testing would have to be done to completely confirm that.

Here are my OS details:
Google Chrome	60.0.3112.113 (Official Build) (64-bit) (cohort: Stable)
Revision	95c454326a7a3153e984e50a4719924968490717-refs/branch-heads/3112@{#744}
OS	Windows
JavaScript	V8 6.0.286.56
Flash	26.0.0.151 C:\Users\amzin\AppData\Local\Google\Chrome\User Data\PepperFlash\26.0.0.151\pepflashplayer.dll
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/5

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Able to reprodcue the issue on windows 7, ubuntu 14.04 and Mac OS 10.12.6 using chrome M60 #60.0.3112.113 and M63 #63.0.3206.0.

This is a regression issue broken in M59 .

Using the per-revision bisect providing the bisect results,
Good build: 59.0.3037.0(Revision: 455955).
Bad build: 59.0.3039.0 (Revision: 456295).

You are probably looking for a change made after 456124 (known good), but no later than 456125 (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/6e26494d0caa38a608ecd3c7852a58387dcaaf96..1bbc9fc2b43ec7b02f5f781ffb70675c5def4220

From the CL above, assigning the issue to the concern owner 

@ wjmaclean- 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.

Review-Url: https://codereview.chromium.org/2745783002

Thanks!

The cause of this bug is not the cl in C#5, though that CL enables the bug. (If it was the cause, then we would expect the scroll-wheel behaviour for the PDF to be wrong when scrolling over the PDF but not over the overlay.)

I suspect this is somehow a mis-interaction between the surface-based hit testing (+ kenrb@) and the mechanism that converts wheels to GestureScroll events (+ dtapuska@).

+mcnee@ and sahel@ as they have both been working on wheel / scroll events in the oopif framework recently. Kevin, do you mind investigating this a bit further?

When scrolling a debug build with the wheel over the PDF & overlay regions, the following DCHECK is triggered:

[1:1:0906/090250.117713:FATAL:browser_plugin.cc(518)] Check failed: blink::WebInputEvent::kGestureTapDown == event.GetType() || gesture_event.resending_plugin_id == browser_plugin_instance_id_. 
#0 0x7f293c88ac77 base::debug::StackTrace::StackTrace()
#1 0x7f293c8b1a31 logging::LogMessage::~LogMessage()
#2 0x7f293a2223d9 content::BrowserPlugin::HandleInputEvent()
#3 0x7f29354184e3 blink::WebPluginContainerImpl::HandleGestureEvent()
#4 0x7f2935417a86 blink::WebPluginContainerImpl::HandleEvent()
#5 0x7f29355a9540 blink::HTMLPlugInElement::DefaultEventHandler()
#6 0x7f29352aabd6 blink::EventDispatcher::DispatchEventPostProcess()
#7 0x7f29352aa13a blink::EventDispatcher::Dispatch()
#8 0x7f29352a904e blink::EventDispatchMediator::DispatchEvent()
#9 0x7f29352a9298 blink::EventDispatcher::DispatchEvent()
#10 0x7f2935725286 blink::ScrollManager::HandleGestureScrollEvent()
#11 0x7f293570e31a blink::EventHandler::HandleGestureScrollEvent()
#12 0x7f2935428486 blink::WebViewImpl::HandleGestureEvent()
#13 0x7f2935a75765 blink::PageWidgetDelegate::HandleInputEvent()
#14 0x7f2935429dc6 blink::WebViewImpl::HandleInputEvent()
#15 0x7f293a26b862 content::RenderWidgetInputHandler::HandleInputEvent()
#16 0x7f293a311c60 content::RenderWidget::HandleInputEvent()
#17 0x7f293a307c61 content::RenderViewImpl::HandleInputEvent()
#18 0x7f293a26a923 content::QueuedWebInputEvent::Dispatch()
#19 0x7f293a269f5b content::MainThreadEventQueue::DispatchEvents()
#20 0x7f293c88b4e9 base::debug::TaskAnnotator::RunTask()
#21 0x7f29343aa1ac blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#22 0x7f29343a7d44 blink::scheduler::TaskQueueManager::DoWork()

This makes me wonder if we're hit-testing the wheel to the top-level RenderWidgetHostView, creating a GestureScroll from it and targeting the GestureScroll to the guest RenderWidgetHostView (or maybe vice-versa, not sure).

Adjusting this to pri-2 since it's not a recent regression (it's taken 3+ milestones for anyone to report it ...)

Surface-based hit testing is somewhat broken when overlays are present (see  bug 755515 ), probably until we can replace the hit testing system with what is being built in the Viz service.

The strange behavior here is probably from BrowserPlugin using a mix of renderer-to-renderer event forwarding and direct routing via surface-based hit testing. It would be good to understand this better and then assess whether it needs to be fixed before all the problematic code is replaced anyway.

The target in RenderWidgetHostInputEventRouter::RouteMouseWheelEvent when scrolling the PDF through the overlay is the root RenderWidgetHostView, not the guest's.

Hence the gesture scroll events are generated in the root. When blink gets them, it would know that the overlay is not the target due to "pointer-events: none", so it targets the plugin element. Then BrowserPlugin::HandleInputEvent sees the gesture scroll and DCHECKs because the mouse wheel should have been routed to the guest's RWHV.

OOPIFs are also affected, so this isn't BrowserPlugin specific. The issue is presumably what's described in  crbug.com/755515#c6  where the surface-based hit testing doesn't go through elements with "pointer-events: none".

This should be fixed in M65.