Refactor browser process coordinate transformation methods

Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/a12ade9d1326ecce585dda08a027d8061e9f06c6
Cr-Commit-Position: refs/heads/master@{#408666}

[kenrb, 2016-07-27 16:53:19]

Description was changed from

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
==========

to

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[kenrb, 2016-07-27 16:54:08]

The CQ bit was checked by kenrb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-27 16:54:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-27 18:05:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-27 18:05:05]

Dry run: This issue passed the CQ dry run.

[kenrb, 2016-07-27 19:45:47]

Description was changed from

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[kenrb, 2016-07-27 20:02:24]

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

[kenrb, 2016-07-27 20:02:25]

nasko: PTAL?

[nasko, 2016-07-27 22:52:13]

Few comments. Overall it will be nice for someone else more familiar with
coordinate transformations and surfaces to review it as well.

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
File content/browser/frame_host/cross_process_frame_connector.cc (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
content/browser/frame_host/cross_process_frame_connector.cc:184: if (!root_view)
How would root_view be null?

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
File content/browser/frame_host/cross_process_frame_connector.h (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
content/browser/frame_host/cross_process_frame_connector.h:109: gfx::Point
TransformPointToCoordSpaceForView(
bikeshed: TransformPointToViewCoordSpace? Since you have the pattern of
TransformPointTo(...)CoordSpace.

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
File content/browser/frame_host/render_widget_host_view_child_frame.h (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
content/browser/frame_host/render_widget_host_view_child_frame.h:190: // to the
frame tree.
Is this the case only when we have started navigation in a new frame but we
haven't committed it yet?

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/delegated_frame_host.h (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/delegated_frame_host.h:175: // Give a
RenderWidgetHostViewBase that renders to a Surface that is
nit: Given?

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/delegated_frame_host.h:177: // the Surfaces and
apply it to a pont. If a Surfaec has not yet been
nit: "a point"? "Surface"

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_view_aura.cc:2060:
target_view);
Do we need a call to gfx::ConvertPointToDIP here like in the LocalCoordSpace
case?

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_view_base.cc (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_view_base.cc:411:
RenderWidgetHostViewBase* target_view) {
target_view here should be |this|, right? Maybe add a DCHECK to ensure we don't
call it incorrectly.

[kenrb, 2016-07-28 16:23:29]

The CQ bit was checked by kenrb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-28 16:23:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kenrb, 2016-07-28 16:24:35]

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

[kenrb, 2016-07-28 16:24:38]

lfg: PTAL, as someone more familiar with Surface coordinate spaces?

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
File content/browser/frame_host/cross_process_frame_connector.cc (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
content/browser/frame_host/cross_process_frame_connector.cc:184: if (!root_view)
On 2016/07/27 22:52:13, nasko wrote:
> How would root_view be null?

I don't know, but it might be possible for it to happen in a nested WebContents
during, for instance, a renderer crash. I doubt it can happen for OOPIFs (and
just ran SitePerProcessBrowserTest.* with a DCHECK in
GetRootRenderWidgetHostView), but I am reluctant to remove all of the guards
because I don't know if there is adequate test coverage for OOPIF-webview.

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
File content/browser/frame_host/cross_process_frame_connector.h (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
content/browser/frame_host/cross_process_frame_connector.h:109: gfx::Point
TransformPointToCoordSpaceForView(
On 2016/07/27 22:52:13, nasko wrote:
> bikeshed: TransformPointToViewCoordSpace? Since you have the pattern of
> TransformPointTo(...)CoordSpace.

I feel like it is slightly more intuitive as it is. 'RootCoordSpace' and
'LocalCoordSpace' should be obvious, but I think 'CoordSpaceForView' conveys a
little better that the coordinate space target is an argument and not something
already known to the callee.

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
File content/browser/frame_host/render_widget_host_view_child_frame.h (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/frame_host/...
content/browser/frame_host/render_widget_host_view_child_frame.h:190: // to the
frame tree.
On 2016/07/27 22:52:13, nasko wrote:
> Is this the case only when we have started navigation in a new frame but we
> haven't committed it yet?

I think there are a couple of cases, but yes the View and FrameConnector aren't
linked until CommitPending(). I believe there are destruction paths that can
result in this also.

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/delegated_frame_host.h (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/delegated_frame_host.h:175: // Give a
RenderWidgetHostViewBase that renders to a Surface that is
On 2016/07/27 22:52:13, nasko wrote:
> nit: Given?

Done.

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/delegated_frame_host.h:177: // the Surfaces and
apply it to a pont. If a Surfaec has not yet been
On 2016/07/27 22:52:13, nasko wrote:
> nit: "a point"? "Surface"

Done.

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_view_aura.cc:2060:
target_view);
On 2016/07/27 22:52:13, nasko wrote:
> Do we need a call to gfx::ConvertPointToDIP here like in the LocalCoordSpace
> case?

No, because that ends up happening later on when the point is passed to the
target_view, but that's a good point and it deserves a comment, which I have
added.

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_view_base.cc (right):

https://codereview.chromium.org/2184033003/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_view_base.cc:411:
RenderWidgetHostViewBase* target_view) {
On 2016/07/27 22:52:13, nasko wrote:
> target_view here should be |this|, right? Maybe add a DCHECK to ensure we
don't
> call it incorrectly.

Not generally, this is really just a stub implementation to cover Android which
doesn't have any of the support for this yet. I have added a NOTREACHED() to
make this clearer.

[commit-bot: I haz the power, 2016-07-28 17:40:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-28 17:41:00]

Dry run: This issue passed the CQ dry run.

[lfg, 2016-07-28 19:58:58]

Code looks good, I just have 1 suggestion and one question.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
File content/browser/frame_host/cross_process_frame_connector.cc (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/cross_process_frame_connector.cc:143: surface_id);
nit: indent.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/cross_process_frame_connector.cc:167:
original_surface, local_surface_id, &transform)) {
nit: indent.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
File content/browser/frame_host/cross_process_frame_connector.h (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/cross_process_frame_connector.h:105: gfx::Point
TransformPointToLocalCoordSpace(
Since this can be used to get transform matrixes between two arbitrary surfaces
(as long as they are embedded in each other), can you move it to SurfaceManager?
I think it makes more sense there. You'll still need to keep the DIPS/Pixels
conversion here, since SurfaceManager operates only in pixels.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
File content/browser/frame_host/render_widget_host_view_child_frame.cc (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/render_widget_host_view_child_frame.cc:548:
surface_id_);
nit: indent.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_aura.cc:2063:
target_view);
nit: indent.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_base.h (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_base.h:244: // coordinate
space of an embedding, or embedded, Surface. Typically this
Is this comment change correct here? I can see that your changes to
CrossProcessFrameConnector allows the API to be used in either direction, but
not here. My understanding is that the |original_surface| always need to be
contained in the RWHVB's surface, but not the other way around.

[kenrb, 2016-07-28 21:18:56]

The CQ bit was checked by kenrb@chromium.org to run a CQ dry run

[kenrb, 2016-07-28 21:19:08]

PTAL again.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
File content/browser/frame_host/cross_process_frame_connector.cc (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/cross_process_frame_connector.cc:143: surface_id);
On 2016/07/28 19:58:58, lfg wrote:
> nit: indent.

This is how git cl format indents it.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/cross_process_frame_connector.cc:167:
original_surface, local_surface_id, &transform)) {
On 2016/07/28 19:58:58, lfg wrote:
> nit: indent.

Ditto, git cl format.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
File content/browser/frame_host/cross_process_frame_connector.h (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/cross_process_frame_connector.h:105: gfx::Point
TransformPointToLocalCoordSpace(
On 2016/07/28 19:58:58, lfg wrote:
> Since this can be used to get transform matrixes between two arbitrary
surfaces
> (as long as they are embedded in each other), can you move it to
SurfaceManager?
> I think it makes more sense there. You'll still need to keep the DIPS/Pixels
> conversion here, since SurfaceManager operates only in pixels.

SurfaceManager doesn't seem quite right because this isn't related to management
of Surfaces in any way. It seems more aligned with the hit testing code, since
this ends up basically being a wrapper for GetTransformToTargetSurface() that
let's us remove a small amount of code duplication between here and
DelegatedFrameHost. Accordingly I have added a method to the SurfaceHittest
class for this purpose.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
File content/browser/frame_host/render_widget_host_view_child_frame.cc (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/render_widget_host_view_child_frame.cc:548:
surface_id_);
On 2016/07/28 19:58:58, lfg wrote:
> nit: indent.

Same as others.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_base.h (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_base.h:244: // coordinate
space of an embedding, or embedded, Surface. Typically this
On 2016/07/28 19:58:58, lfg wrote:
> Is this comment change correct here? I can see that your changes to
> CrossProcessFrameConnector allows the API to be used in either direction, but
> not here. My understanding is that the |original_surface| always need to be
> contained in the RWHVB's surface, but not the other way around.

Since RenderWidgetHostViewChildFrame uses CrossProcessFrameConnector's method,
it can be either embedding or embedded by original_surface.
RenderWidgetHostViewAura and Mac require it to be embedded, but they are always
the root surface so there is no need to account for the other direction.

[commit-bot: I haz the power, 2016-07-28 21:19:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[lfg, 2016-07-28 21:30:28]

Sorry about the indents, for some reason rietveld is adding an extra space there
for me.

lgtm.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
File content/browser/frame_host/cross_process_frame_connector.h (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/frame_h...
content/browser/frame_host/cross_process_frame_connector.h:105: gfx::Point
TransformPointToLocalCoordSpace(
On 2016/07/28 21:19:08, kenrb wrote:
> On 2016/07/28 19:58:58, lfg wrote:
> > Since this can be used to get transform matrixes between two arbitrary
> surfaces
> > (as long as they are embedded in each other), can you move it to
> SurfaceManager?
> > I think it makes more sense there. You'll still need to keep the DIPS/Pixels
> > conversion here, since SurfaceManager operates only in pixels.
> 
> SurfaceManager doesn't seem quite right because this isn't related to
management
> of Surfaces in any way. It seems more aligned with the hit testing code, since
> this ends up basically being a wrapper for GetTransformToTargetSurface() that
> let's us remove a small amount of code duplication between here and
> DelegatedFrameHost. Accordingly I have added a method to the SurfaceHittest
> class for this purpose.

Acknowledged.

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_base.h (right):

https://codereview.chromium.org/2184033003/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_base.h:244: // coordinate
space of an embedding, or embedded, Surface. Typically this
On 2016/07/28 21:19:08, kenrb wrote:
> On 2016/07/28 19:58:58, lfg wrote:
> > Is this comment change correct here? I can see that your changes to
> > CrossProcessFrameConnector allows the API to be used in either direction,
but
> > not here. My understanding is that the |original_surface| always need to be
> > contained in the RWHVB's surface, but not the other way around.
> 
> Since RenderWidgetHostViewChildFrame uses CrossProcessFrameConnector's method,
> it can be either embedding or embedded by original_surface.
> RenderWidgetHostViewAura and Mac require it to be embedded, but they are
always
> the root surface so there is no need to account for the other direction.

Acknowledged.

[kenrb, 2016-07-28 22:02:04]

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

[kenrb, 2016-07-28 22:02:05]

jbauman: PTAL for cc/surfaces?

[commit-bot: I haz the power, 2016-07-28 22:45:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-28 22:45:51]

Dry run: Try jobs failed on following builders:
  linux_site_isolation on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_site_isol...)

[jbauman, 2016-07-29 01:22:45]

lgtm

[kenrb, 2016-07-29 13:59:40]

nasko can you have another look please?

[nasko, 2016-07-29 14:19:47]

There is one test that is hitting the DCHECK you've added. Overall the CL LGTM
once that is fixed.

https://codereview.chromium.org/2184033003/diff/40001/content/browser/rendere...
File content/browser/renderer_host/delegated_frame_host.cc (right):

https://codereview.chromium.org/2184033003/diff/40001/content/browser/rendere...
content/browser/renderer_host/delegated_frame_host.cc:236: DCHECK(false);
This DCHECK is hitting in an OOPIF fullscreen test.

Another note - without {} around the DCHECK, would it be removed by the
preprocessor in release build, putting the return statement to be in the
conditional? Maybe just add {} to be on the safe side?

[kenrb, 2016-07-29 16:20:23]

https://codereview.chromium.org/2184033003/diff/40001/content/browser/rendere...
File content/browser/renderer_host/delegated_frame_host.cc (right):

https://codereview.chromium.org/2184033003/diff/40001/content/browser/rendere...
content/browser/renderer_host/delegated_frame_host.cc:236: DCHECK(false);
On 2016/07/29 14:19:46, nasko wrote:
> This DCHECK is hitting in an OOPIF fullscreen test.
> 

This is annoying, but I think the best thing is to remove the DCHECK here. The
problem seems to be that in tests we can load a page and then hide the tab
before the compositor frames have all finished propagating, making coordinate
transformation impossible. This is a race condition and potentially a lot of
tests could do things like that, so it might be best just to allow the
transformation to silently fail in that case. It shouldn't be a problem because
the page with the bad transformation is not visible.

> Another note - without {} around the DCHECK, would it be removed by the
> preprocessor in release build, putting the return statement to be in the
> conditional? Maybe just add {} to be on the safe side?

DCHECK is defined as (void (0)) in release configurations to prevent that sort
of thing. If it was completely removed this method wouldn't compile because it
would have a path with no return statement.

[kenrb, 2016-07-29 16:22:28]

The CQ bit was checked by kenrb@chromium.org

[kenrb, 2016-07-29 16:22:28]

The patchset sent to the CQ was uploaded after l-g-t-m from nasko@chromium.org,
jbauman@chromium.org, lfg@chromium.org
Link to the patchset: https://codereview.chromium.org/2184033003/#ps60001
(title: "Removed problematic DCHECK")

[commit-bot: I haz the power, 2016-07-29 16:23:07]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-29 17:07:04]

Description was changed from

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[commit-bot: I haz the power, 2016-07-29 17:07:06]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-07-29 17:10:12]

Description was changed from

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Refactor browser process coordinate transformation code

The current Surface-based coordinate transformation methods are only
useful for transforming coordinates from a child frame's coordinate
space to the root's space. More flexibility is needed for delivering
MouseMove events to multiple renderer processes for the sake of
MouseEnter and MouseLeave event handlers. This CL reworks the exposed
methods in RenderWidgetHostViewBase and DelegatedFrameHost to provide
that flexibility.

BUG=632035
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/a12ade9d1326ecce585dda08a027d8061e9f06c6
Cr-Commit-Position: refs/heads/master@{#408666}
==========

[commit-bot: I haz the power, 2016-07-29 17:10:14]

Patchset 4 (id:??) landed as
https://crrev.com/a12ade9d1326ecce585dda08a027d8061e9f06c6
Cr-Commit-Position: refs/heads/master@{#408666}