Embed a simple Mojo shell in content

Embed a simple Mojo shell in content

This CL adds an ApplicationManager to the browser and sets it up for static
application loading in-process and out-of-process (via the utility process)
in Chrome.

This also adds a new proxy_resolver component which is a thin Mojo app
wrapping the Mojo resolver impl in //net/proxy.

Finally, this hooks up the proxy_resolver app to Chrome's Mojo shell for
(flag-dependent) in-process or out-of-process operation.

[xhwang, 2015-05-13 04:36:19]

xhwang@chromium.org changed reviewers:
+ xhwang@chromium.org

[xhwang, 2015-05-13 04:36:20]

https://codereview.chromium.org/1128453004/diff/1/chrome/browser/chrome_conte...
File chrome/browser/chrome_content_browser_client.cc (right):

https://codereview.chromium.org/1128453004/diff/1/chrome/browser/chrome_conte...
chrome/browser/chrome_content_browser_client.cc:2461:
switches::kV8PacMojoInProcess)) {
For media, I am using a gyp/gn variable and a macro:

https://code.google.com/p/chromium/codesearch#chromium/src/media/mojo/service...

https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...

What's the preference here? Shall I also switch to using command line options?

https://codereview.chromium.org/1128453004/diff/1/chrome/common/application_u...
File chrome/common/application_urls.cc (right):

https://codereview.chromium.org/1128453004/diff/1/chrome/common/application_u...
chrome/common/application_urls.cc:9: const char kProxyResolver[] =
"system:proxy_resolver";
what's the naming convention for this? In html_viewer, we used to have something
like mojo:media.

https://codereview.chromium.org/1128453004/diff/1/content/browser/mojo_shell_...
File content/browser/mojo_shell_context_impl.cc (right):

https://codereview.chromium.org/1128453004/diff/1/content/browser/mojo_shell_...
content/browser/mojo_shell_context_impl.cc:58:
process_host->SetName(base::UTF8ToUTF16("Mojo Application"));
This will appear in task manager and is visible to users. We'll need difference
name for different applications. For mojo media app, it should be something like
"Media".

[Ken Rockot(use gerrit already), 2015-05-13 05:12:07]

On 2015/05/13 04:36:20, xhwang wrote:
>
https://codereview.chromium.org/1128453004/diff/1/chrome/browser/chrome_conte...
> File chrome/browser/chrome_content_browser_client.cc (right):
> 
>
https://codereview.chromium.org/1128453004/diff/1/chrome/browser/chrome_conte...
> chrome/browser/chrome_content_browser_client.cc:2461:
> switches::kV8PacMojoInProcess)) {
> For media, I am using a gyp/gn variable and a macro:
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/media/mojo/service...
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...
> 
> What's the preference here? Shall I also switch to using command line options?
> 
>
https://codereview.chromium.org/1128453004/diff/1/chrome/common/application_u...
> File chrome/common/application_urls.cc (right):
> 
>
https://codereview.chromium.org/1128453004/diff/1/chrome/common/application_u...
> chrome/common/application_urls.cc:9: const char kProxyResolver[] =
> "system:proxy_resolver";
> what's the naming convention for this? In html_viewer, we used to have
something
> like mojo:media.

This remains an open question. There had been talk of abandoning the mojo scheme
altogether, and I think it's probably a good idea to avoid these special schemes
in general. I was thinking it might make sense to use canonical chromium.org
URLs for embedded apps, letting the shell embedder (e.g. chrome) resolve them
appropriately.

I'm not sure what Mandoline intends to do, but we should standardize on a common
approach if possible.


>
https://codereview.chromium.org/1128453004/diff/1/content/browser/mojo_shell_...
> File content/browser/mojo_shell_context_impl.cc (right):
> 
>
https://codereview.chromium.org/1128453004/diff/1/content/browser/mojo_shell_...
> content/browser/mojo_shell_context_impl.cc:58:
> process_host->SetName(base::UTF8ToUTF16("Mojo Application"));
> This will appear in task manager and is visible to users. We'll need
difference
> name for different applications. For mojo media app, it should be something
like
> "Media".

Yep. This is a detail that's sort of glossed over for now. We will want the
process to expose a name provided by the mojo app. I'm not sure how we'll do
that yet. It might end up being the loader's responsibility at least in the
short term.

[xhwang, 2015-05-13 05:19:20]

I like this CL because I can use the existing MojoMediaApplication directly:

https://code.google.com/p/chromium/codesearch#chromium/src/media/mojo/service...

I do have one question though. Applications should also be able to use services
provided by the browser. This is possible because each application can get
access to the Shell. However, in my case, each application instance is bound to
a RenderFrame, and the services provided by the browser process should also be
specific to a RenderFrame, this is needed to enforce the security origin. For
example, the mojo application may want to use some storage (e.g. file system, or
web storage). In browser, all storages are per origin. How can the browser know
which application is bound to which origin?

https://codereview.chromium.org/1128453004/diff/1/content/public/common/proce...
File content/public/common/process.mojom (right):

https://codereview.chromium.org/1128453004/diff/1/content/public/common/proce...
content/public/common/process.mojom:15: interface Process {
This is more like an ApplicationLoader interface. The fact that the application
is loaded in another process is an implementation detail. The only difference is
the LaunchResult, which could probably be replaced by a  LoadResult?

[Ken Rockot(use gerrit already), 2015-05-13 05:20:12]

On 2015/05/13 05:12:07, Ken Rockot wrote:
> On 2015/05/13 04:36:20, xhwang wrote:
> >
>
https://codereview.chromium.org/1128453004/diff/1/chrome/browser/chrome_conte...
> > File chrome/browser/chrome_content_browser_client.cc (right):
> > 
> >
>
https://codereview.chromium.org/1128453004/diff/1/chrome/browser/chrome_conte...
> > chrome/browser/chrome_content_browser_client.cc:2461:
> > switches::kV8PacMojoInProcess)) {
> > For media, I am using a gyp/gn variable and a macro:
> > 
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/media/mojo/service...
> > 
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...
> > 
> > What's the preference here? Shall I also switch to using command line
options?
> > 
> >
>
https://codereview.chromium.org/1128453004/diff/1/chrome/common/application_u...
> > File chrome/common/application_urls.cc (right):
> > 
> >
>
https://codereview.chromium.org/1128453004/diff/1/chrome/common/application_u...
> > chrome/common/application_urls.cc:9: const char kProxyResolver[] =
> > "system:proxy_resolver";
> > what's the naming convention for this? In html_viewer, we used to have
> something
> > like mojo:media.
> 
> This remains an open question. There had been talk of abandoning the mojo
scheme
> altogether, and I think it's probably a good idea to avoid these special
schemes
> in general. I was thinking it might make sense to use canonical
http://chromium.org
> URLs for embedded apps, letting the shell embedder (e.g. chrome) resolve them
> appropriately.
> 
> I'm not sure what Mandoline intends to do, but we should standardize on a
common
> approach if possible.
> 
> 
> >
>
https://codereview.chromium.org/1128453004/diff/1/content/browser/mojo_shell_...
> > File content/browser/mojo_shell_context_impl.cc (right):
> > 
> >
>
https://codereview.chromium.org/1128453004/diff/1/content/browser/mojo_shell_...
> > content/browser/mojo_shell_context_impl.cc:58:
> > process_host->SetName(base::UTF8ToUTF16("Mojo Application"));
> > This will appear in task manager and is visible to users. We'll need
> difference
> > name for different applications. For mojo media app, it should be something
> like
> > "Media".
> 
> Yep. This is a detail that's sort of glossed over for now. We will want the
> process to expose a name provided by the mojo app. I'm not sure how we'll do
> that yet. It might end up being the loader's responsibility at least in the
> short term.

Also regarding the in-process/out-of-process question, I think it's fine to
approach on a case-by-case basis. If media will remain in-process in Chrome for
now, it's probably fine to leave as a build flag.

[Ken Rockot(use gerrit already), 2015-05-15 19:15:08]

Sorry, I missed these questions before.

On 2015/05/13 05:19:20, xhwang wrote:
> I like this CL because I can use the existing MojoMediaApplication directly:
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/media/mojo/service...
> 
> I do have one question though. Applications should also be able to use
services
> provided by the browser. This is possible because each application can get
> access to the Shell. However, in my case, each application instance is bound
to
> a RenderFrame, and the services provided by the browser process should also be
> specific to a RenderFrame, this is needed to enforce the security origin. For
> example, the mojo application may want to use some storage (e.g. file system,
or
> web storage). In browser, all storages are per origin. How can the browser
know
> which application is bound to which origin?
>

This is something we still meed to sort out. My current thinking is that because
the Shell knows which RenderFrame is initiating a connection, it can attach
origin information to the connection request received by the target app. We'd
need to modify some application interfaces to support that.

>
https://codereview.chromium.org/1128453004/diff/1/content/public/common/proce...
> File content/public/common/process.mojom (right):
> 
>
https://codereview.chromium.org/1128453004/diff/1/content/public/common/proce...
> content/public/common/process.mojom:15: interface Process {
> This is more like an ApplicationLoader interface. The fact that the
application
> is loaded in another process is an implementation detail. The only difference
is
> the LaunchResult, which could probably be replaced by a  LoadResult?

Ultimately this will probably get used by the shell to configure process sandbox
too. The intent is for it to be a general-purpose child process control service.
I am however renaming it to ProcessControl, FWIW.

[xhwang, 2015-05-20 21:18:34]

Is there any plan to move this work forward?

[Ken Rockot(use gerrit already), 2015-05-20 21:21:04]

Waiting on the next Mojo roll to get the main content patch in. Roll is in
progress but blocking on Windows test failures (and in turn blocking on
corp workstation woes).

I've already started moving bits of this upstream though. Hoping to land
the rest this week!

On Wed, May 20, 2015 at 2:18 PM, <xhwang@chromium.org> wrote:

> Is there any plan to move this work forward?
>
> https://codereview.chromium.org/1128453004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[xhwang, 2015-05-20 21:24:57]

Thanks for the update! Glad to hear we are making progress!

On Wed, May 20, 2015 at 2:21 PM, Ken Rockot <rockot@chromium.org> wrote:

> Waiting on the next Mojo roll to get the main content patch in. Roll is in
> progress but blocking on Windows test failures (and in turn blocking on
> corp workstation woes).
>
> I've already started moving bits of this upstream though. Hoping to land
> the rest this week!
>
> On Wed, May 20, 2015 at 2:18 PM, <xhwang@chromium.org> wrote:
>
>> Is there any plan to move this work forward?
>>
>> https://codereview.chromium.org/1128453004/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2015-05-27 21:23:55]

Closing this CL.

https://codereview.chromium.org/1149833007/ replaces it and is currently up for
review.