Route ScrollEvents to correct process under OOPIF

Route ScrollEvents to correct process under OOPIF

On ChromeOS, trackpad scroll events are not routed to the an OOPIF
even when the mouse cursor is over one. This is because ScrollEvents
are transformed to WheelEvents and then passed directly to the
top-level frame's RenderWidgetHost, and don't use the path of other
WheelEvents that invokes the RenderWidgetHostInputEventRouter for
browser process hit testing.

This CL causes the events generated on reception of a ScrollEvent
by a RenderWidgetHostViewAura to be hit tested and sent to the
appropriate RenderWidgetHostView.

BUG=615445
Committed: https://crrev.com/0b678205722777a678aa0ae3a2610cae7a4efbce
Cr-Commit-Position: refs/heads/master@{#401671}

[kenrb, 2016-06-23 14:22:24]

kenrb@chromium.org changed reviewers:
+ dtapuska@chromium.org

[kenrb, 2016-06-23 14:22:25]

Dave,

I don't know if this is at all related to the bug you were looking at, but I
think it fixes the --site-per-process problem with trackpad scrolling.

[kenrb, 2016-06-23 14:26:22]

Description was changed from

==========
Route ScrollEvents to correct process under OOPIF

On ChromeOS, trackpad scroll events are not routed to the an OOPIF
even when the mouse cursor is over one. This is because ScrollEvents
are transformed to WheelEvents and then passed directly to the
top-level frame's RenderWidgetHost, and don't use the path of other
WheelEvents that invokes the RenderWidgetHostInputEventRouter for
browser process hit testing.

This CL causes the events generated on reception of a ScrollEvent
by a RenderWidgetHostViewAura to be hit tested and sent to the
appropriate RenderWidgetHostView.

BUG=615445
==========

to

==========
Route ScrollEvents to correct process under OOPIF

On ChromeOS, trackpad scroll events are not routed to the an OOPIF
even when the mouse cursor is over one. This is because ScrollEvents
are transformed to WheelEvents and then passed directly to the
top-level frame's RenderWidgetHost, and don't use the path of other
WheelEvents that invokes the RenderWidgetHostInputEventRouter for
browser process hit testing.

This CL causes the events generated on reception of a ScrollEvent
by a RenderWidgetHostViewAura to be hit tested and sent to the
appropriate RenderWidgetHostView.

BUG=615445
==========

[kenrb, 2016-06-23 16:28:56]

kenrb@chromium.org changed reviewers:
+ wjmaclean@chromium.org
- dtapuska@chromium.org

[kenrb, 2016-06-23 16:28:57]

James: Does this look okay to you? You're probably the person with the most
knowledge of the intersection of RWHIER and scrolling, so I'd appreciate any
thoughts before I ask a content owner for review.

[wjmaclean, 2016-06-23 16:49:28]

On 2016/06/23 16:28:57, kenrb wrote:
> James: Does this look okay to you? You're probably the person with the most
> knowledge of the intersection of RWHIER and scrolling, so I'd appreciate any
> thoughts before I ask a content owner for review.

Yes, this seems reasonable: lgtm.

[kenrb, 2016-06-23 17:25:26]

kenrb@chromium.org changed reviewers:
+ creis@chromium.org

[kenrb, 2016-06-23 17:25:26]

Charlie can you take a pass for owner review? It adds another Aura-only test to
site_per_process_browsertest.cc but I think that just becomes another to be
moved for the bug you filed. I verified locally that it fixes the trackpad
scroll problem on a Chromebook.

[Charlie Reis, 2016-06-23 17:37:09]

LGTM!

[kenrb, 2016-06-23 17:51:47]

The CQ bit was checked by kenrb@chromium.org

[commit-bot: I haz the power, 2016-06-23 17:52:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2052353002/40001

[commit-bot: I haz the power, 2016-06-23 19:07:53]

Description was changed from

==========
Route ScrollEvents to correct process under OOPIF

On ChromeOS, trackpad scroll events are not routed to the an OOPIF
even when the mouse cursor is over one. This is because ScrollEvents
are transformed to WheelEvents and then passed directly to the
top-level frame's RenderWidgetHost, and don't use the path of other
WheelEvents that invokes the RenderWidgetHostInputEventRouter for
browser process hit testing.

This CL causes the events generated on reception of a ScrollEvent
by a RenderWidgetHostViewAura to be hit tested and sent to the
appropriate RenderWidgetHostView.

BUG=615445
==========

to

==========
Route ScrollEvents to correct process under OOPIF

On ChromeOS, trackpad scroll events are not routed to the an OOPIF
even when the mouse cursor is over one. This is because ScrollEvents
are transformed to WheelEvents and then passed directly to the
top-level frame's RenderWidgetHost, and don't use the path of other
WheelEvents that invokes the RenderWidgetHostInputEventRouter for
browser process hit testing.

This CL causes the events generated on reception of a ScrollEvent
by a RenderWidgetHostViewAura to be hit tested and sent to the
appropriate RenderWidgetHostView.

BUG=615445
==========

[commit-bot: I haz the power, 2016-06-23 19:07:58]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-06-23 19:11:08]

Description was changed from

==========
Route ScrollEvents to correct process under OOPIF

On ChromeOS, trackpad scroll events are not routed to the an OOPIF
even when the mouse cursor is over one. This is because ScrollEvents
are transformed to WheelEvents and then passed directly to the
top-level frame's RenderWidgetHost, and don't use the path of other
WheelEvents that invokes the RenderWidgetHostInputEventRouter for
browser process hit testing.

This CL causes the events generated on reception of a ScrollEvent
by a RenderWidgetHostViewAura to be hit tested and sent to the
appropriate RenderWidgetHostView.

BUG=615445
==========

to

==========
Route ScrollEvents to correct process under OOPIF

On ChromeOS, trackpad scroll events are not routed to the an OOPIF
even when the mouse cursor is over one. This is because ScrollEvents
are transformed to WheelEvents and then passed directly to the
top-level frame's RenderWidgetHost, and don't use the path of other
WheelEvents that invokes the RenderWidgetHostInputEventRouter for
browser process hit testing.

This CL causes the events generated on reception of a ScrollEvent
by a RenderWidgetHostViewAura to be hit tested and sent to the
appropriate RenderWidgetHostView.

BUG=615445

Committed: https://crrev.com/0b678205722777a678aa0ae3a2610cae7a4efbce
Cr-Commit-Position: refs/heads/master@{#401671}
==========

[commit-bot: I haz the power, 2016-06-23 19:11:09]

Patchset 3 (id:??) landed as
https://crrev.com/0b678205722777a678aa0ae3a2610cae7a4efbce
Cr-Commit-Position: refs/heads/master@{#401671}