Move Shell connection to content

Move Shell connection to content.

I want to be able to use Mojo in content, so I think it makes sense that the shell bind step lives in content too.

1. Moves MojoRunnerState to content/common and renames it to MojoShellConnection. This class will be available in any process that creates an impl prior to running the main message loop.

2. Modifies ChildProcessLauncher to create a platform channel pair and put the client handle on the command line of the child process, and registers the server handle with the external shell. This will allow the child process to bind an Application request if it wants.

TODO: What if the child process doesn't bind it? What happens to the instance created in the external shell?
TODO: ChildProcessLauncher is a convenient chokepoint. It means the shell handle is passed to all child processes created by content. Do we want to do this? I think it's OK for now since this code is only triggered if Chrome itself is run from within the external shell. Before we can move this to production I think CreateInstanceForHandle is going to have to take a CapabilityFilter.

R=jam@chromium.org
http://crbug.com/551253

Committed: https://crrev.com/03b7b9d5d01d4b23362a1b9fcd13900fbb11286c
Cr-Commit-Position: refs/heads/master@{#359770}

[Ben Goodger (Google), 2015-11-13 07:06:50]

Description was changed from

==========
Move Shell connection to content.

BUG=
==========

to

==========
Move Shell connection to content.

I want to be able to use Mojo in content, so I think it makes sense that the
shell bind step lives in content too.

1. Moves MojoRunnerState to content/common and renames it to
MojoShellConnection. This class will be available in any process that creates an
impl prior to running the main message loop.

2. Modifies ChildProcessLauncher to create a platform channel pair and put the
client handle on the command line of the child process, and registers the server
handle with the external shell. This will allow the child process to bind an
Application request if it wants.

TODO: What if the child process doesn't bind it? What happens to the instance
created in the external shell?
TODO: ChildProcessLauncher is a convenient chokepoint. It means the shell handle
is passed to all child processes created by content. Do we want to do this? I
think it's OK for now since this code is only triggered if Chrome itself is run
from within the external shell. Before we can move this to production I think
CreateInstanceForHandle is going to have to take a CapabilityFilter.

R=jam@chromium.org
http://crbug.com/551253
==========

[Ben Goodger (Google), 2015-11-13 07:06:50]

ben@chromium.org changed reviewers:
+ jam@chromium.org

[Ben Goodger (Google), 2015-11-13 07:27:17]

Description was changed from

==========
Move Shell connection to content.

I want to be able to use Mojo in content, so I think it makes sense that the
shell bind step lives in content too.

1. Moves MojoRunnerState to content/common and renames it to
MojoShellConnection. This class will be available in any process that creates an
impl prior to running the main message loop.

2. Modifies ChildProcessLauncher to create a platform channel pair and put the
client handle on the command line of the child process, and registers the server
handle with the external shell. This will allow the child process to bind an
Application request if it wants.

TODO: What if the child process doesn't bind it? What happens to the instance
created in the external shell?
TODO: ChildProcessLauncher is a convenient chokepoint. It means the shell handle
is passed to all child processes created by content. Do we want to do this? I
think it's OK for now since this code is only triggered if Chrome itself is run
from within the external shell. Before we can move this to production I think
CreateInstanceForHandle is going to have to take a CapabilityFilter.

R=jam@chromium.org
http://crbug.com/551253
==========

to

==========
Move Shell connection to content.

I want to be able to use Mojo in content, so I think it makes sense that the
shell bind step lives in content too.

1. Moves MojoRunnerState to content/common and renames it to
MojoShellConnection. This class will be available in any process that creates an
impl prior to running the main message loop.

2. Modifies ChildProcessLauncher to create a platform channel pair and put the
client handle on the command line of the child process, and registers the server
handle with the external shell. This will allow the child process to bind an
Application request if it wants.

TODO: What if the child process doesn't bind it? What happens to the instance
created in the external shell?
TODO: ChildProcessLauncher is a convenient chokepoint. It means the shell handle
is passed to all child processes created by content. Do we want to do this? I
think it's OK for now since this code is only triggered if Chrome itself is run
from within the external shell. Before we can move this to production I think
CreateInstanceForHandle is going to have to take a CapabilityFilter.
TODO: This first iteration of the patch carries over the state class' implicit
instantiaton of WindowManagerConnection. Not all users of this class are going
to want to have that (or even be allowed to create it depending on the
CapabilityFilter they're run with). I need to move this out and explicitly
instantiate it only in processes where it's needed.

R=jam@chromium.org
http://crbug.com/551253
==========

[Ben Goodger (Google), 2015-11-13 15:35:11]

Description was changed from

==========
Move Shell connection to content.

I want to be able to use Mojo in content, so I think it makes sense that the
shell bind step lives in content too.

1. Moves MojoRunnerState to content/common and renames it to
MojoShellConnection. This class will be available in any process that creates an
impl prior to running the main message loop.

2. Modifies ChildProcessLauncher to create a platform channel pair and put the
client handle on the command line of the child process, and registers the server
handle with the external shell. This will allow the child process to bind an
Application request if it wants.

TODO: What if the child process doesn't bind it? What happens to the instance
created in the external shell?
TODO: ChildProcessLauncher is a convenient chokepoint. It means the shell handle
is passed to all child processes created by content. Do we want to do this? I
think it's OK for now since this code is only triggered if Chrome itself is run
from within the external shell. Before we can move this to production I think
CreateInstanceForHandle is going to have to take a CapabilityFilter.
TODO: This first iteration of the patch carries over the state class' implicit
instantiaton of WindowManagerConnection. Not all users of this class are going
to want to have that (or even be allowed to create it depending on the
CapabilityFilter they're run with). I need to move this out and explicitly
instantiate it only in processes where it's needed.

R=jam@chromium.org
http://crbug.com/551253
==========

to

==========
Move Shell connection to content.

I want to be able to use Mojo in content, so I think it makes sense that the
shell bind step lives in content too.

1. Moves MojoRunnerState to content/common and renames it to
MojoShellConnection. This class will be available in any process that creates an
impl prior to running the main message loop.

2. Modifies ChildProcessLauncher to create a platform channel pair and put the
client handle on the command line of the child process, and registers the server
handle with the external shell. This will allow the child process to bind an
Application request if it wants.

TODO: What if the child process doesn't bind it? What happens to the instance
created in the external shell?
TODO: ChildProcessLauncher is a convenient chokepoint. It means the shell handle
is passed to all child processes created by content. Do we want to do this? I
think it's OK for now since this code is only triggered if Chrome itself is run
from within the external shell. Before we can move this to production I think
CreateInstanceForHandle is going to have to take a CapabilityFilter.

R=jam@chromium.org
http://crbug.com/551253
==========

[jam, 2015-11-13 23:28:10]

lgtm

https://codereview.chromium.org/1442893002/diff/240001/content/browser/child_...
File content/browser/child_process_launcher.cc (right):

https://codereview.chromium.org/1442893002/diff/240001/content/browser/child_...
content/browser/child_process_launcher.cc:531:
command_line->AppendSwitch("use-new-edk");
are you sure this is needed?
https://code.google.com/p/chromium/codesearch#search/&q=use-new-edk%20file:co...

[Ben Goodger (Google), 2015-11-15 07:39:14]

The CQ bit was checked by ben@chromium.org

[Ben Goodger (Google), 2015-11-15 07:39:15]

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

[commit-bot: I haz the power, 2015-11-15 07:39:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1442893002/450001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1442893002/450001

[commit-bot: I haz the power, 2015-11-15 12:13:20]

Committed patchset #24 (id:450001)

[commit-bot: I haz the power, 2015-11-15 12:15:09]

Patchset 24 (id:??) landed as
https://crrev.com/03b7b9d5d01d4b23362a1b9fcd13900fbb11286c
Cr-Commit-Position: refs/heads/master@{#359770}