Understanding direct event routing for MouseWheel events

[Marshall Greenblatt]

Hi James,

I'm trying to debug a problem [1] with mouse wheel scrolling of the PDF plugin in a Chromium-derived application that uses a custom RenderWidgetHostView implementation for the main view. Specifically, I'm running into this condition that you added to BrowserPlugin::HandleInputEvent in https://crrev.com/1bbc9fc2:

  // With direct event routing turned on, BrowserPlugin should almost never

  // see wheel events any more. The two exceptions are (1) scroll bubbling, and

  // (2) synthetic mouse wheels generated by touchpad GesturePinch events on

  // Mac, which always go to the mainframe and thus may hit BrowserPlugin if

  // it's in a top-level embedder. In both cases we should indicate the event

  // as not handled (for GesturePinch on Mac, indicating the event has been

  // handled leads to touchpad pinch not working).

  if (event.GetType() == blink::WebInputEvent::kMouseWheel)

    return blink::WebInputEventResult::kNotHandled;

The application currently synthesizes a blink::WebMouseWheelEvent and calls ForwardWheelEvent on the RenderWidgetHostImpl owned by the RenderWidgetHostViewGuest. Adding some breakpoints I see that the following methods are being called in order:

RenderWidgetHostImpl::ForwardWheelEvent

MouseWheelEventQueue::TryForwardNextEventToRenderer

-> event_sent_for_gesture_ack_.GetType() == kMouseWheel

MouseWheelEventQueue::ProcessMouseWheelAck

RenderWidgetHostViewGuest::WheelEventAck

BrowserPluginGuest::ResendEventToEmbedder

RenderWidgetHostImpl::ForwardWheelEventWithLatencyInfo

MouseWheelEventQueue::TryForwardNextEventToRenderer

-> event_sent_for_gesture_ack_.GetType() == kMouseWheel

MouseWheelEventQueue::SendScrollBegin

BrowserPlugin::HandleInputEvent

-> returns kNotHandled

WebPluginContainerImpl::HandleGestureEvent

-> event.GetType() == kGestureScrollUpdate

MouseWheelEventQueue::ProcessMouseWheelAck

PepperWebPluginImpl::HandleInputEvent

-> returns false due to event_class == 0

Can you explain what "direct event routing" means, and where/how MouseWheel events are supposed to be routed for the PDF plugin in M59 and newer?

Thanks,

Marshall

[1] https://bitbucket.org/chromiumembedded/cef/issues/2078

[W. James MacLean]

By "direct routing" we mean that the MouseWheels get targeted directly to the guest's RenderWidgetHostView from RenderWidgetHostInputEventRouter instead of first going to the top-level RenderWidgethostView{Aura|Mac|...} and hitting the BrowserPlugin, and then having to go back to the browser. These events end up going back to the BrowserPluginGuest and then get forwarded to the RenderWidgetHostViewGuest.

Whether an event gets routed depends on functions like RenderWidgetHostViewEventHandler::ShouldRouteEvent():

https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_event_handler.cc?rcl=3fc057c54155174850badc5c6b3bfd9b1ec2d955&l=889

Routing can also be affected by whether the mouse is locked, or the wheel events are "latched" to the parent view (e.g. a wheel scroll starts with the mouse pointer over the parent, but it moves over the guest as the scroll progresses, but the events still go to the parent until the scroll event 'stops').

Hope this helps, but please follow up with any additional questions you may have.

-J

[Marshall Greenblatt]

On Fri, Jun 23, 2017 at 1:08 PM, W. James MacLean <wjma...@chromium.org> wrote:

By "direct routing" we mean that the MouseWheels get targeted directly to the guest's RenderWidgetHostView from RenderWidgetHostInputEventRouter instead of first going to the top-level RenderWidgethostView{Aura|Mac|...} and hitting the BrowserPlugin, and then having to go back to the browser. These events end up going back to the BrowserPluginGuest and then get forwarded to the RenderWidgetHostViewGuest.

Thanks, that's what I was missing :). Passing the event into RWHVGuest::ProcessMouseWheelEvent instead of RWHI::ForwardWheelEvent (and the same for MouseEvent) fixed the scrolling problem.

[Marshall Greenblatt]

Hi James,

I've run into a strange problem now where the mouse events stop working after I send a keyboard event. For example, if I press the down arrow on the keyboard the PDF view will scroll, but afterwards it will no longer show any mouse input (clicks, wheel, etc). Keyboard events still work (down/up arrow for scrolling). Any idea what might be going on there?

Thanks,

Marshall