mus: Use a barebone mus client-lib in chrome-renderer.

mus: Use a barebone mus client-lib in chrome-renderer.

Notable changes:
. Add RendererWindowTreeClient that implements ui.mojom.WindowTreeClient
  interface for chrome-renderer. It currently supports the most basic
  functionalities. For example, it does not receive events (the events
  instead are routed through chrome-browser), it does not support more
  than one window, window state changes (e.g. bounds, visibility etc.)
  are ignored (the corresponding messages from chrome-browser are used
  instead) etc. Over time however, this implementation will grow.
. When chrome-renderer is running as a mus-client, it immediately creates
  a RendererWindowTreeClient instance for a RenderWidget, instead of
  waiting for a creation request from chrome-browser.
. Remove RenderWidgetMusConnection, since it's no longer needed.

BUG=672913
Review-Url: https://codereview.chromium.org/2648213002
Cr-Commit-Position: refs/heads/master@{#446257}
Committed: https://chromium.googlesource.com/chromium/src/+/602ce136fcac0b2a338a5708f857cf12f8a77467

[sadrul, 2017-01-23 21:43:22]

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

[commit-bot: I haz the power, 2017-01-23 21:43:54]

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, 2017-01-23 21:56:16]

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

[commit-bot: I haz the power, 2017-01-23 21:56:17]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[sadrul, 2017-01-23 22:58:42]

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

[sadrul, 2017-01-23 22:59:35]

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

[commit-bot: I haz the power, 2017-01-23 22:59:56]

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, 2017-01-23 23:22:20]

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

[commit-bot: I haz the power, 2017-01-23 23:22:21]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)

[sadrul, 2017-01-24 01:36:26]

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

[commit-bot: I haz the power, 2017-01-24 01:37:24]

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

[sadrul, 2017-01-24 01:44:39]

Description was changed from

==========
[exp] mus: Use a barebone mus client-lib in chrome-renderer.

BUG=672913
==========

to

==========
mus: Use a barebone mus client-lib in chrome-renderer.

Notable changes:
. Add RendererWindowTreeClient that implements ui.mojom.WindowTreeClient
  interface for chrome-renderer. It currently supports the most basic
  functionalities. For example, it does not receive events (the events
  instead are routed through chrome-browser), it does not support more
  than one window, window state changes (e.g. bounds, visibility etc.)
  are ignored (the corresponding messages from chrome-browser are used
  instead) etc. Over time however, this implementation will grow.
. When chrome-renderer is running as a mus-client, it immediately creates
  a RendererWindowTreeClient instance for a RenderWidget, instead of
  waiting for a creation request from chrome-browser.
. Remove RenderWidgetMusConnection, since it's no longer needed.

BUG=672913
==========

[sadrul, 2017-01-24 01:51:44]

sadrul@chromium.org changed reviewers:
+ fsamuel@chromium.org, sky@chromium.org

[Fady Samuel, 2017-01-24 02:04:38]

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
File content/renderer/mus/renderer_window_tree_client.cc (right):

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.cc:127: NOTIMPLEMENTED();
We would get to here when an OOPIF submits a CompositorFrame on resize. The
parent should embed that SurfaceInfo. Basically this should make its way to
ChildFrameCompositingHelper. Speaking of which, ChildFrameCompositingHelper
should probably take in a SurfaceReferenceFactory at construction.

[Fady Samuel, 2017-01-24 02:07:18]

This LGTM though. There's a bunch of work to do for OOPIF but we can deal with
that when we get to it.

[commit-bot: I haz the power, 2017-01-24 02:56:29]

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

[commit-bot: I haz the power, 2017-01-24 02:56:30]

Dry run: This issue passed the CQ dry run.

[sky, 2017-01-24 17:39:31]

Nice!

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
File content/renderer/mus/renderer_window_tree_client.h (right):

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.h:28: class
RendererWindowTreeClient : public ui::mojom::WindowTreeClient {
Add description. Also, document what threading assumptions are.

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.h:77: const
std::vector<gfx::Rect>& new_additional_client_areas) override {}
Style guide says not to inline virtual overriden functions.

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.h:140: int routing_id_;
const

[sadrul, 2017-01-24 17:58:17]

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

[commit-bot: I haz the power, 2017-01-24 17:58:30]

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

[sadrul, 2017-01-24 18:02:41]

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
File content/renderer/mus/renderer_window_tree_client.cc (right):

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.cc:127: NOTIMPLEMENTED();
On 2017/01/24 02:04:38, Fady Samuel wrote:
> We would get to here when an OOPIF submits a CompositorFrame on resize. The
> parent should embed that SurfaceInfo. Basically this should make its way to
> ChildFrameCompositingHelper. Speaking of which, ChildFrameCompositingHelper
> should probably take in a SurfaceReferenceFactory at construction.

Acknowledged.

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
File content/renderer/mus/renderer_window_tree_client.h (right):

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.h:28: class
RendererWindowTreeClient : public ui::mojom::WindowTreeClient {
On 2017/01/24 17:39:31, sky wrote:
> Add description. Also, document what threading assumptions are.

Done.

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.h:77: const
std::vector<gfx::Rect>& new_additional_client_areas) override {}
On 2017/01/24 17:39:31, sky wrote:
> Style guide says not to inline virtual overriden functions.

Done.

https://codereview.chromium.org/2648213002/diff/100001/content/renderer/mus/r...
content/renderer/mus/renderer_window_tree_client.h:140: int routing_id_;
On 2017/01/24 17:39:31, sky wrote:
> const

Done.

[sky, 2017-01-24 18:13:48]

LGTM

[sadrul, 2017-01-24 18:22:20]

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

[sadrul, 2017-01-24 18:22:22]

+creis@ as content owner for render_widget.cc and render_thread_impl.cc changes.

[commit-bot: I haz the power, 2017-01-24 19:33:50]

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

[commit-bot: I haz the power, 2017-01-24 19:33:51]

Dry run: This issue passed the CQ dry run.

[Charlie Reis, 2017-01-24 21:21:45]

Sanity check: the new RendererWindowTreeClient class will work with OOPIFs,
where the RenderWidget may be for a subframe (or an A-B-A case with multiple
widgets for A in the same process), right?  If so, sounds good.

Other than that, render_widget.cc and render_thread_impl.cc LGTM.

[sadrul, 2017-01-24 21:41:17]

On 2017/01/24 21:21:45, Charlie Reis wrote:
> Sanity check: the new RendererWindowTreeClient class will work with OOPIFs,
> where the RenderWidget may be for a subframe (or an A-B-A case with multiple
> widgets for A in the same process), right?  If so, sounds good.

The new RendererWindowTreeClient class is expected to handle the OOPIF cases
too, yes. But those are yet unimplemented (see TODO in
OnEmbeddedAppDisconnected(), OnWindowDeleted() etc., for example). Although, for
RenderWidget that host oopif, I think we would not want a
RendererWindowTreeClient() to be created (i.e. it should be created only for the
'root' frame in that process). In that case, looks like I should move the
creation of RendererWindowTreeClient into RenderWidget::Init() so that it's not
created when |for_oopif_| is set?

> 
> Other than that, render_widget.cc and render_thread_impl.cc LGTM.

[sadrul, 2017-01-24 21:47:31]

On 2017/01/24 21:41:17, sadrul wrote:
> On 2017/01/24 21:21:45, Charlie Reis wrote:
> > Sanity check: the new RendererWindowTreeClient class will work with OOPIFs,
> > where the RenderWidget may be for a subframe (or an A-B-A case with multiple
> > widgets for A in the same process), right?  If so, sounds good.
> 
> The new RendererWindowTreeClient class is expected to handle the OOPIF cases
> too, yes. But those are yet unimplemented (see TODO in
> OnEmbeddedAppDisconnected(), OnWindowDeleted() etc., for example). Although,
for
> RenderWidget that host oopif, I think we would not want a
> RendererWindowTreeClient() to be created (i.e. it should be created only for
the
> 'root' frame in that process). In that case, looks like I should move the
> creation of RendererWindowTreeClient into RenderWidget::Init() so that it's
not
> created when |for_oopif_| is set?

Just to be super-clear, in the A-B-A case:

 . In A, there are three RenderWidget objects, with |for_oopif_| set to true for
one, and to false for two.
 . In B, there are two RenderWidget objects, with |for_oopif_| set to true for
one, and to false for the other.

Is that correct? If so, in A, for the two RenderWidgets with |for_oopif_| set to
false, is it possible to tell which is the 'root' in the hierarchy?

[Charlie Reis, 2017-01-24 21:53:15]

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

[Charlie Reis, 2017-01-24 21:53:16]

[+dcheng, kenrb]

On 2017/01/24 21:41:17, sadrul wrote:
> On 2017/01/24 21:21:45, Charlie Reis wrote:
> > Sanity check: the new RendererWindowTreeClient class will work with OOPIFs,
> > where the RenderWidget may be for a subframe (or an A-B-A case with multiple
> > widgets for A in the same process), right?  If so, sounds good.
> 
> The new RendererWindowTreeClient class is expected to handle the OOPIF cases
> too, yes. But those are yet unimplemented (see TODO in
> OnEmbeddedAppDisconnected(), OnWindowDeleted() etc., for example). Although,
for
> RenderWidget that host oopif, I think we would not want a
> RendererWindowTreeClient() to be created (i.e. it should be created only for
the
> 'root' frame in that process). In that case, looks like I should move the
> creation of RendererWindowTreeClient into RenderWidget::Init() so that it's
not
> created when |for_oopif_| is set?

Hmm, your reply raises more questions than answers.  :)

You mention that RendererWindowTreeClient is expected to handle OOPIF cases, but
then you say that we shouldn't create a RendererWindowTreeClient for OOPIF
RenderWidgets, which I don't understand.

To clarify, assume we have a frame A1, with subframe B1, with nested subframe
A2.  A1 and A2 are in process A, and B1 is in process B.

Process A has a RenderFrame and RenderWidget for A1, a RenderFrameProxy for B1
(no RenderWidget), and a RenderFrame and RenderWidget for A2.
Conversely, process B has a RenderFrameProxy for A1, a RenderFrame and
RenderWidget for B1, and a RenderFrameProxy for A2.

Previously, I assumed you wanted each of those 3 RenderWidgets to each have its
own RendererWindowTreeClient, but now I'm unclear.  Should there be a
RendererWindowTreeClient for B1?  Should there be one for A2?

[Charlie Reis, 2017-01-24 21:53:41]

[+site-isolation-reviews]

[Charlie Reis, 2017-01-24 21:55:59]

On 2017/01/24 21:47:31, sadrul wrote:
> On 2017/01/24 21:41:17, sadrul wrote:
> > On 2017/01/24 21:21:45, Charlie Reis wrote:
> > > Sanity check: the new RendererWindowTreeClient class will work with
OOPIFs,
> > > where the RenderWidget may be for a subframe (or an A-B-A case with
multiple
> > > widgets for A in the same process), right?  If so, sounds good.
> > 
> > The new RendererWindowTreeClient class is expected to handle the OOPIF cases
> > too, yes. But those are yet unimplemented (see TODO in
> > OnEmbeddedAppDisconnected(), OnWindowDeleted() etc., for example). Although,
> for
> > RenderWidget that host oopif, I think we would not want a
> > RendererWindowTreeClient() to be created (i.e. it should be created only for
> the
> > 'root' frame in that process). In that case, looks like I should move the
> > creation of RendererWindowTreeClient into RenderWidget::Init() so that it's
> not
> > created when |for_oopif_| is set?
> 
> Just to be super-clear, in the A-B-A case:
> 
>  . In A, there are three RenderWidget objects, with |for_oopif_| set to true
for
> one, and to false for two.
>  . In B, there are two RenderWidget objects, with |for_oopif_| set to true for
> one, and to false for the other.
> 
> Is that correct? If so, in A, for the two RenderWidgets with |for_oopif_| set
to
> false, is it possible to tell which is the 'root' in the hierarchy?

Ah, our replies crossed paths.  No, A has 2 RenderWidgets and B has 1. 
for_oopif_ is true for B1 and A2, and false for A1.

[sadrul, 2017-01-25 01:09:33]

On 2017/01/24 21:55:59, Charlie Reis wrote:
> On 2017/01/24 21:47:31, sadrul wrote:
> > On 2017/01/24 21:41:17, sadrul wrote:
> > > On 2017/01/24 21:21:45, Charlie Reis wrote:
> > > > Sanity check: the new RendererWindowTreeClient class will work with
> OOPIFs,
> > > > where the RenderWidget may be for a subframe (or an A-B-A case with
> multiple
> > > > widgets for A in the same process), right?  If so, sounds good.
> > > 
> > > The new RendererWindowTreeClient class is expected to handle the OOPIF
cases
> > > too, yes. But those are yet unimplemented (see TODO in
> > > OnEmbeddedAppDisconnected(), OnWindowDeleted() etc., for example).
Although,
> > for
> > > RenderWidget that host oopif, I think we would not want a
> > > RendererWindowTreeClient() to be created (i.e. it should be created only
for
> > the
> > > 'root' frame in that process). In that case, looks like I should move the
> > > creation of RendererWindowTreeClient into RenderWidget::Init() so that
it's
> > not
> > > created when |for_oopif_| is set?
> > 
> > Just to be super-clear, in the A-B-A case:
> > 
> >  . In A, there are three RenderWidget objects, with |for_oopif_| set to true
> for
> > one, and to false for two.
> >  . In B, there are two RenderWidget objects, with |for_oopif_| set to true
for
> > one, and to false for the other.
> > 
> > Is that correct? If so, in A, for the two RenderWidgets with |for_oopif_|
set
> to
> > false, is it possible to tell which is the 'root' in the hierarchy?
> 
> Ah, our replies crossed paths.  No, A has 2 RenderWidgets and B has 1. 
> for_oopif_ is true for B1 and A2, and false for A1.

OK, then yes, I think the current CL is OK, i.e. we should be creating a
RendererWindowTreeClient per RenderWidget (regardless of whether |for_oopif_| is
set or not). Thanks for the explanation!

Do you have any other concerns? Or should I put this in the CQ?

[Charlie Reis, 2017-01-25 20:54:14]

On 2017/01/25 01:09:33, sadrul wrote:
> On 2017/01/24 21:55:59, Charlie Reis wrote:
> > On 2017/01/24 21:47:31, sadrul wrote:
> > > On 2017/01/24 21:41:17, sadrul wrote:
> > > > On 2017/01/24 21:21:45, Charlie Reis wrote:
> > > > > Sanity check: the new RendererWindowTreeClient class will work with
> > OOPIFs,
> > > > > where the RenderWidget may be for a subframe (or an A-B-A case with
> > multiple
> > > > > widgets for A in the same process), right?  If so, sounds good.
> > > > 
> > > > The new RendererWindowTreeClient class is expected to handle the OOPIF
> cases
> > > > too, yes. But those are yet unimplemented (see TODO in
> > > > OnEmbeddedAppDisconnected(), OnWindowDeleted() etc., for example).
> Although,
> > > for
> > > > RenderWidget that host oopif, I think we would not want a
> > > > RendererWindowTreeClient() to be created (i.e. it should be created only
> for
> > > the
> > > > 'root' frame in that process). In that case, looks like I should move
the
> > > > creation of RendererWindowTreeClient into RenderWidget::Init() so that
> it's
> > > not
> > > > created when |for_oopif_| is set?
> > > 
> > > Just to be super-clear, in the A-B-A case:
> > > 
> > >  . In A, there are three RenderWidget objects, with |for_oopif_| set to
true
> > for
> > > one, and to false for two.
> > >  . In B, there are two RenderWidget objects, with |for_oopif_| set to true
> for
> > > one, and to false for the other.
> > > 
> > > Is that correct? If so, in A, for the two RenderWidgets with |for_oopif_|
> set
> > to
> > > false, is it possible to tell which is the 'root' in the hierarchy?
> > 
> > Ah, our replies crossed paths.  No, A has 2 RenderWidgets and B has 1. 
> > for_oopif_ is true for B1 and A2, and false for A1.
> 
> OK, then yes, I think the current CL is OK, i.e. we should be creating a
> RendererWindowTreeClient per RenderWidget (regardless of whether |for_oopif_|
is
> set or not). Thanks for the explanation!
> 
> Do you have any other concerns? Or should I put this in the CQ?

Great-- LGTM then.  (Sorry for the delayed reply!)

[sadrul, 2017-01-25 21:14:14]

The CQ bit was checked by sadrul@chromium.org

[sadrul, 2017-01-25 21:14:15]

The patchset sent to the CQ was uploaded after l-g-t-m from fsamuel@chromium.org
Link to the patchset: https://codereview.chromium.org/2648213002/#ps120001
(title: ".")

[commit-bot: I haz the power, 2017-01-25 21:15:10]

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

[sadrul, 2017-01-25 21:31:05]

On 2017/01/25 20:54:14, Charlie Reis wrote:
> On 2017/01/25 01:09:33, sadrul wrote:
> > On 2017/01/24 21:55:59, Charlie Reis wrote:
> > > On 2017/01/24 21:47:31, sadrul wrote:
> > > > On 2017/01/24 21:41:17, sadrul wrote:
> > > > > On 2017/01/24 21:21:45, Charlie Reis wrote:
> > > > > > Sanity check: the new RendererWindowTreeClient class will work with
> > > OOPIFs,
> > > > > > where the RenderWidget may be for a subframe (or an A-B-A case with
> > > multiple
> > > > > > widgets for A in the same process), right?  If so, sounds good.
> > > > > 
> > > > > The new RendererWindowTreeClient class is expected to handle the OOPIF
> > cases
> > > > > too, yes. But those are yet unimplemented (see TODO in
> > > > > OnEmbeddedAppDisconnected(), OnWindowDeleted() etc., for example).
> > Although,
> > > > for
> > > > > RenderWidget that host oopif, I think we would not want a
> > > > > RendererWindowTreeClient() to be created (i.e. it should be created
only
> > for
> > > > the
> > > > > 'root' frame in that process). In that case, looks like I should move
> the
> > > > > creation of RendererWindowTreeClient into RenderWidget::Init() so that
> > it's
> > > > not
> > > > > created when |for_oopif_| is set?
> > > > 
> > > > Just to be super-clear, in the A-B-A case:
> > > > 
> > > >  . In A, there are three RenderWidget objects, with |for_oopif_| set to
> true
> > > for
> > > > one, and to false for two.
> > > >  . In B, there are two RenderWidget objects, with |for_oopif_| set to
true
> > for
> > > > one, and to false for the other.
> > > > 
> > > > Is that correct? If so, in A, for the two RenderWidgets with
|for_oopif_|
> > set
> > > to
> > > > false, is it possible to tell which is the 'root' in the hierarchy?
> > > 
> > > Ah, our replies crossed paths.  No, A has 2 RenderWidgets and B has 1. 
> > > for_oopif_ is true for B1 and A2, and false for A1.
> > 
> > OK, then yes, I think the current CL is OK, i.e. we should be creating a
> > RendererWindowTreeClient per RenderWidget (regardless of whether
|for_oopif_|
> is
> > set or not). Thanks for the explanation!
> > 
> > Do you have any other concerns? Or should I put this in the CQ?
> 
> Great-- LGTM then.  (Sorry for the delayed reply!)

(Not at all! Thank you for the quick review!)

[commit-bot: I haz the power, 2017-01-26 00:25:26]

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

[commit-bot: I haz the power, 2017-01-26 00:25:27]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[sadrul, 2017-01-26 01:30:23]

The CQ bit was checked by sadrul@chromium.org

[commit-bot: I haz the power, 2017-01-26 01:31:29]

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, 2017-01-26 01:35:59]

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

[commit-bot: I haz the power, 2017-01-26 01:36:01]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[sadrul, 2017-01-26 01:54:27]

The CQ bit was checked by sadrul@chromium.org

[commit-bot: I haz the power, 2017-01-26 01:55:08]

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, 2017-01-26 04:46:02]

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

[commit-bot: I haz the power, 2017-01-26 04:46:04]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[sadrul, 2017-01-26 05:55:21]

The CQ bit was checked by sadrul@chromium.org

[commit-bot: I haz the power, 2017-01-26 05:55:37]

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, 2017-01-26 06:41:16]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1485410121775740,
"parent_rev": "271891581a5ffa67adb2abb15c856cd15b5a0e6c", "commit_rev":
"602ce136fcac0b2a338a5708f857cf12f8a77467"}

[commit-bot: I haz the power, 2017-01-26 06:42:11]

Description was changed from

==========
mus: Use a barebone mus client-lib in chrome-renderer.

Notable changes:
. Add RendererWindowTreeClient that implements ui.mojom.WindowTreeClient
  interface for chrome-renderer. It currently supports the most basic
  functionalities. For example, it does not receive events (the events
  instead are routed through chrome-browser), it does not support more
  than one window, window state changes (e.g. bounds, visibility etc.)
  are ignored (the corresponding messages from chrome-browser are used
  instead) etc. Over time however, this implementation will grow.
. When chrome-renderer is running as a mus-client, it immediately creates
  a RendererWindowTreeClient instance for a RenderWidget, instead of
  waiting for a creation request from chrome-browser.
. Remove RenderWidgetMusConnection, since it's no longer needed.

BUG=672913
==========

to

==========
mus: Use a barebone mus client-lib in chrome-renderer.

Notable changes:
. Add RendererWindowTreeClient that implements ui.mojom.WindowTreeClient
  interface for chrome-renderer. It currently supports the most basic
  functionalities. For example, it does not receive events (the events
  instead are routed through chrome-browser), it does not support more
  than one window, window state changes (e.g. bounds, visibility etc.)
  are ignored (the corresponding messages from chrome-browser are used
  instead) etc. Over time however, this implementation will grow.
. When chrome-renderer is running as a mus-client, it immediately creates
  a RendererWindowTreeClient instance for a RenderWidget, instead of
  waiting for a creation request from chrome-browser.
. Remove RenderWidgetMusConnection, since it's no longer needed.

BUG=672913

Review-Url: https://codereview.chromium.org/2648213002
Cr-Commit-Position: refs/heads/master@{#446257}
Committed:
https://chromium.googlesource.com/chromium/src/+/602ce136fcac0b2a338a5708f857...
==========

[commit-bot: I haz the power, 2017-01-26 06:42:13]

Committed patchset #7 (id:120001) as
https://chromium.googlesource.com/chromium/src/+/602ce136fcac0b2a338a5708f857...