Convert the Pepper Talk API to use the new resource system.

Convert the Pepper Talk API to use the new resource system.

This uses the new resource call/reply system and removes the special casing
for the messages in the PPAPI plugin and the special filter attached to all
child process hosts. This also adds permissions checking (it requires private
permissions to use this API).

BUG=

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=170017

[brettw, 2012-11-09 23:36:58]

I think I hooked everything up properly, but I have no idea how to test this!

[Josh Horwich, 2012-11-15 03:32:18]

On 2012/11/09 23:36:58, brettw wrote:
> I think I hooked everything up properly, but I have no idea how to test this!

Sorry I haven't gotten back sooner, I haven't forgotten about this CL.

Currently there is no simple way to test this - other than building a ChromeOS
build and manually testing :(   Last time we touched these interfaces there was
some discussion around automating things (see comments 6 and later in
crbug.com/137952) but no progress yet - this CL is motivating me to improve
things.

This inspired me - I've written a simple mock of the plugin that only exercises
these interfaces, and a simple HTML page to invoke it. This plugin can be run
against a chromeos=1 (Aura) build on Linux to exercise the code manually.
Tomorrow I'll look into automating it (although the dialog itself requires user
interaction as it is a chrome::ShowMessageBox invocation), or at least packaging
up my mock plugin/page so you can try it locally as well.

[Josh Horwich, 2012-11-16 23:29:45]

lgtm (+1 nit/question)

On 2012/11/15 03:32:18, Josh Horwich wrote:
> On 2012/11/09 23:36:58, brettw wrote:
> > I think I hooked everything up properly, but I have no idea how to test
this!
> 
> Sorry I haven't gotten back sooner, I haven't forgotten about this CL.
> 
> Currently there is no simple way to test this - other than building a ChromeOS
> build and manually testing :(   Last time we touched these interfaces there
was
> some discussion around automating things (see comments 6 and later in
> crbug.com/137952) but no progress yet - this CL is motivating me to improve
> things.
> 
> This inspired me - I've written a simple mock of the plugin that only
exercises
> these interfaces, and a simple HTML page to invoke it. This plugin can be run
> against a chromeos=1 (Aura) build on Linux to exercise the code manually.
> Tomorrow I'll look into automating it (although the dialog itself requires
user
> interaction as it is a chrome::ShowMessageBox invocation), or at least
packaging
> up my mock plugin/page so you can try it locally as well.

[Josh Horwich, 2012-11-17 01:01:59]

Oops, didn't publish the nit/question... see below.

https://codereview.chromium.org/11359147/diff/2001/chrome/browser/renderer_ho...
File chrome/browser/renderer_host/pepper/pepper_talk_host.cc (right):

https://codereview.chromium.org/11359147/diff/2001/chrome/browser/renderer_ho...
chrome/browser/renderer_host/pepper/pepper_talk_host.cc:43: // should use the
toplevel window associated with the render view.
nit: I'm not the expert in this area (ash) but I believe a system modal like
this does want to use the active root window. Should the above TODO comment be
removed?

[brettw, 2012-11-19 22:15:38]

https://codereview.chromium.org/11359147/diff/2001/chrome/browser/renderer_ho...
File chrome/browser/renderer_host/pepper/pepper_talk_host.cc (right):

https://codereview.chromium.org/11359147/diff/2001/chrome/browser/renderer_ho...
chrome/browser/renderer_host/pepper/pepper_talk_host.cc:43: // should use the
toplevel window associated with the render view.
I'm not qualified to know for sure, but I believe Ben would say this should go
up the layers of abstraction rather than jump out to UI code in the middle of
everything here.

[brettw, 2012-11-28 19:15:06]

TBR=jschuh for ipc messages (they don't actually have any parameters so we
should be pretty safe).