Apps V2 in Pepper: introduce singleton resource ExtensionsCommon.

Apps V2 in Pepper: introduce singleton resource ExtensionsCommon.

ExtensionsCommon will be the plugin-renderer bridge for those 'simple'
APIs whose input/output can be easily represented by base::ListValue.

The host side implementation will be in a separate CL.

BUG=None
TEST=None


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

[yzshen1, 2013-03-26 00:51:03]

Hi, Raymes.

Would you please take a look? Thanks!

[raymes, 2013-03-27 16:52:08]

This is quite nice. lgtm after addressing the one comment.

https://codereview.chromium.org/13080002/diff/1/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/13080002/diff/1/ppapi/proxy/ppapi_messages.h#...
ppapi/proxy/ppapi_messages.h:1338:
IPC_MESSAGE_CONTROL0(PpapiHostMsg_ExtensionsCommon_Create)
Could you please comment each of these and explain its use and what each of its
arguments are for (see e.g. web socket or others).

[yzshen1, 2013-03-27 22:31:40]

Thanks Raymes!

Brett: please do an OWNER review for chrome_renderer.gypi.

Justin: please do a review for ppapi_messages.h. The data passed by these
messages will eventually be relayed to the browser process by
ExtensionHostMsg_Request messages. I think they should be safe as long as we are
confident that ExtensionHostMsg_Request is safe.

Thanks!

https://codereview.chromium.org/13080002/diff/1/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/13080002/diff/1/ppapi/proxy/ppapi_messages.h#...
ppapi/proxy/ppapi_messages.h:1338:
IPC_MESSAGE_CONTROL0(PpapiHostMsg_ExtensionsCommon_Create)
On 2013/03/27 16:52:08, raymes wrote:
> Could you please comment each of these and explain its use and what each of
its
> arguments are for (see e.g. web socket or others).

Done.

[brettw, 2013-03-28 04:14:13]

.gypi lgtm

[jschuh, 2013-03-28 11:28:14]

Just to clarify, this appears to be just proxying to the normal interface
JavaScript extensions use. So, restrictions on what APIs an extension can call
are already implicitly enforced at the process level, and this CL has no way
around that?

[yzshen, 2013-03-28 18:20:10]

Thanks Brett and Justin!

Correct. In renderer, the requests will be relayed to the RequestSender
used by the JS extension APIs. And from that point on, it follows the same
code path to the browser process. At the browser process, requests should
be validated. This CL has no way around it.

FYI, the CL that connects these requests to RequestSender is here:
https://chromiumcodereview.appspot.com/12567028/


On Thu, Mar 28, 2013 at 4:28 AM, <jschuh@chromium.org> wrote:

> Just to clarify, this appears to be just proxying to the normal interface
> JavaScript extensions use. So, restrictions on what APIs an extension can
> call
> are already implicitly enforced at the process level, and this CL has no
> way
> around that?
>
>
https://codereview.chromium.**org/13080002/<https://codereview.chromium.org/1...
>



-- 
Best regards,
Yuzhu Shen.

[jschuh, 2013-03-28 18:27:57]

okay. rubberstamp ipc lgtm for ipc security since the immediate use of the
fields doesn't look scary and the permissions are enforced at the process level.

[commit-bot: I haz the power, 2013-03-28 20:38:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yzshen@chromium.org/13080002/8001

[commit-bot: I haz the power, 2013-03-29 03:29:23]

Change committed as 191278