NaCl trusted plugin refactoring -- what remains?

[Mark Seaborn]

We've done a lot of the refactoring work that we'd planned to do [1] on the NaCl trusted plugin:

• Justin converted a lot of SRPC-using code to using Chrome IPC.
• Justin changed it so that the plugin code is linked directly into Chromium rather than being a separate DLL/DSO.
• I moved src/trusted/plugin/ to components/nacl/renderer/plugin/, and moved ppb_nacl_private.h out of ppapi/.

It's now clear that we can start integrating nacl/renderer/ and nacl/renderer/plugin/ more closely.  The code in nacl/renderer/plugin/ should be able to use base/ and Chrome IPC.

But, by itself, that would still leave plugin/plugin.cc as defining an in-process pp::Instance.  Is there a plan for how to refactor that too?

For example:

• Is there a part of Chromium that we can have call more directly into components/nacl/renderer/plugin/?
• What code remains for implementing in-process plugins?
• Does this include things like SwitchToOutOfProcessProxy()?  (Is that what switches a NaCl plugin from being in-process to out-of-process?)

Cheers,

Mark

[1] "NaCl trusted plugin refactoring", May 2013-Feb 2014: https://docs.google.com/a/chromium.org/document/d/1KlseJLJk3A21MZ41r7VW8rVg5qvoEIp__uzyAbjL4Lk/edit

[Bill Budge]

ChromeContentRendererClient is where we start launching a NaCl trusted plugin, and it can know about src/components/nacl, so it seems like a good place to do this.

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/renderer/chrome_content_renderer_client.cc&l=743

We still have to create a blink::WebPlugin so the browser can talk to the plugin. That happens in src/content, and we probably want to keep it there, since there are a lot of paths in ChromeContentRendererClient for blocking plugins and pre-rendering.

https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/render_frame_impl.cc&rcl=1424177669&l=1715

In src/content, we can't know about NaCl but we cheat and have the concept of an 'External' plugin, which is a euphemism for NaCl. I don't think anything but NaCl uses this. We can add a method to content::ContentRendererClient to create an external plugin and override it in ChromeContentRendererClient to do what we want.

I'm not sure how hard this will be.

[David Michael]

I hadn't thought in detail about it, but my thinking was that ultimately we'd want to make a PluginPlaceholder for NaCl. Similar to how we do missing or disabled plugins:
https://code.google.com/p/chromium/codesearch#chromium/src/components/plugins/renderer/loadable_plugin_placeholder.h&rcl=1424206797&l=16

The NaCl one could do all the necessary resource fetching, etc, and never invoke any Pepper stuff until the untrusted module is ready to be initialized. This would get rid of a bunch of the "SwitchToOutOfProcessProxy" complexity.

I haven't thought hard about where this lives and how we "hook" plugin loading to determine if something needs the NaClPluginPlaceholder.

We also need to make sure we still show support for the NaCl MIME types, even after the NaCl plugin is gone.

(I.e. "navigator.mimeTypes['application/x-nacl']')

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