Google chrome extension with NPAPI moving to NaCl

Question

I have recently developed a google chrome extension that uses an NPAPI plugin made using the FireBreath framework. I just now found out that google will shortly discontinue these types of plugins and eventually ban all existing extensions that use them. So, I would like to eventually move to the NaCl / PPAPI architecture, but I am not sure if this architecture can even support what I am currently doing in the NPAPI plugin.

In my current NPAPI plugin I am supporting OSX and Windows. On the OSX version, the plugin executes the system() function which executes a small 1 line applescript. It looks like this:

osascript -e 'tell app ... 

On the windows version, it executes functions in a COM library. Both versions end up doing the same exact thing. Another option I have is executing a python script, if I were to go this route, I would most likely want to embed python in the native component.

Is any of this possible anymore with NaCl / PPAPI?

Balliett

Answer 1

Since you are already using an extension, you may want to look at Native Messaging as a replacement for your use of NPAPI.

Chromomere

Native Messaging won't work because the process I am interacting with does not support it. – Balliett

You said you developed an NPAPI plugin; in the native messaging model, the process your extension talks to would be a binary that you made, which would have the same code as your NPAPI plugin, minus all the NPAPI glue, and with the native-side native message handling instead. The process you are ultimately talking to presumably does support being loaded as an NPAPI plugin either, but that doesn't mean NPAPI didn't work as the intermediary. – Chromomere

Yeah I realize I can make a bridge, but this will be my last resort. I liked that the NPAPI component comes packaged in one easy to install bundle from the extension store. Having to install the browser extension then install a separate native component is something I would not want to do if I can help it. – Balliett

Answer 2

The ability to run arbitrary system() function or execute arbitrary functions from a COM library is #1 reason for NPAPI deprecation. Ditto for execution of a python script (you can execute python script in NaCl, of course - but it'll not be able to call system() function or a COM library either).

It's not news: as was noted in the Chrome Comic book on the day of Chromium release NPAPI plugins are unrestricted and that it's a big problem: http://www.google.com/googlebooks/chrome/small_30.html

It was obvious even back then that this situation can only be tolerated for so long. Plugins were tolerated for five years because some important things were unimplemenatble without them but now it's time to kill plugins and make sure nothing in browser can access OS directly.

If you want to implement some functionality which can not be implemented in browser currently because there are no appropriate API the right way is to ask about it on chromium-dev and add this API to Chromium (and perhaps other browsers, too). For example access to COM ports (not libraries) was added recently (see http://developer.chrome.com/apps/app_hardware.html).

Atiptoe

What the plugin actually does currently is interacts with skype. It sets the skype status. Its disappointing I will soon no longer be able to do this in a stock chrome browser. Thanks for the feedback, I will ask around on chromium-dev. – Balliett

We are years away from the day where the browser can handle everything. Filesystem access, for example, the current sandbox JS APIs do not work if you need to edit the file in a real app, like Autocad. All Google's decision will do is entrench IE in the enterprise. – Gourde

Answer 3

If you don't need an interaction between browser and the application, you can use external protocol support. You need to register protocol in the registry on Windows. I don't know how external protocols work on OSX. When user clicks external protocol link, Chrome shows a dialog which allows user to launch the application.

Gambrill