Outdated page

We're leaving this here for the discussion it contains, but please help us update the new FireBreath 2.0 section of this website.

The Beginning of the End of NPAPI (last updated in 2014)

Many of you have no-doubt seen the news that Chrome will be phasing out support for NPAPI in the next year.

The FireBreath team thinks that that is a Really Bad Idea and welcomes any of the browser vendors to contact them directly via phone or email to discuss the reasons.

Unfortunately, we at FireBreath can see the writing on the wall. NPAPI is going away.  It shouldn't – there isn't a good replacement.  It's frustrating, infuriating, and implies a frightening disregard for the innovation that plugins allow on the web (to be confirmed after a review of PPAPI). Recent decisions by the Mozilla and Chrome teams, however, point a very clear finger that the browser development teams are declaring a relatively quiet war of attrition on plugins and they will be gone soon.  In addition, Windows 8 and later contains a modern mode (formerly called Metro) of IE that disables almost all ActiveX controls.

The conclusion is inevitable: We will need to change our approach.

EDIT: To clarify, FireFox has made it more difficult for NPAPI plugins, but when used properly Click to Play isn't that much of an impediment.  It definitely shows that they want NPAPI plugins gone, but they haven't (yet anyway) made any announcements that indicate any sudden or imminent demise of NPAPI support. Chrome is the only browser that has, and there is not much so far to indicate exactly when that will happen.


FireBreath 2.0 will support current protocols as well as Native Messaging, but hypothetically could support any of the following

Major changes will include:

Other improvements:

The basic plan:

FireBreath 2.0 attempt to address several long-standing complaints about the framework as well as adding a whole new type of plugin support.  With the collaboration of the employees at GradeCam and other members of the community we've developed of the FireWyrm protocol.  This name was carefully chosen using the same naming methodology as FireBreath itself, which is top secret.  The point, though, is that the FireWyrm interface will allow a whole new type of plugin transports.

Adding support for the FireWyrm protocol involved a fair bit of complexity, but at its core it is actually a distinct thing from FireBreath -- it could be used in other projects, if someone wanted to.  In essence, FireWyrm is an advanced (but suprisingly simple) mechanism for performing RPC calls over an essentially text-based asynchronous transport protocol using JSON.

What does this mean?

You have three pieces to this system:

  1. FireWyrm client (FireWyrmJS will be our initial javascript implementation)
  2. FireWyrm provider (FireBreath's third plugin type, a sibling to ActiveX and NPAPI)
  3. A tranport mechanism for communicating between them, known as a WyrmHole

FireWyrmJS connects over a WyrmHole to the FireBreath plugin (through the provider) and gets information about the root JSAPI object; it then constructs a javascript object wrapper which can create a payload, send it over the WyrmHole, and return a Promise for all plugin calls.  (If you aren't familiar with the Promise pattern, and in particular the Promises/A+ spec, you may want to read up on it a bit).

What this means is that any transport mechanism that you can find that will connect the two points of code and send strings back and forth can be used to connect to this plugin.  On the C++ side a new set of FireWyrm provider entrypoints have been created which make it relatively easy to create the c++ side of the WyrmHole.  The initial implementation of a WyrmHole (nearly complete) uses Native Client in order to instantiate the plugin.  We'll essentially create a thin executable which will load your FireBreath 2.0 plugin using the FireWyrm entrypoints and will communicate with the browser, allowing you to use your same plugin.


I'm sure any of you that is actually thinking about what I'm proposing has already noticed that there are some deviations and challenges with this idea.  I'm not sure I've identified them all, but here are the things I can think of off-hand that will change or need to be addressed:

--- Below is the previous version of this page containing brainstorms and info which was used to develop the above plans. It has not been updated in awhile ---

The alternatives, as presented by the browser manufacturers

The browser development teams seem to feel that dropping NPAPI support is acceptable for a number of reasons.  One of the main reasons is that a very small percentage of people use plugins; unfortunately, for that small percentage, there are no other good options (PPAPI may be a good option - to be confirmed).  Here are the options that they feel we should be able to use in their place:

(this list focusses primarily on Chrome since that's the most immediate, but the goal is to find a solution or conglomerate of solutions that can be combined to make a long term multi-browser solution)

Pepper Plugin API / PPAPI (without NaCL) (link)

We have confirmed that PPAPI will not work because while Chrome supports it they don't provide any way for third parties to install PPAPI plugins.  The only method of doing so involves a command-line argument, which is unsuitable for most purposes.

However, PPAPI can be used in conjunction with NaCL - see below.

Google Native Client / NaCl (link)

Google Native Messaging (link)

Mozilla Extensions js-ctypes (link)

Web Sockets and an external application

--- This page is under construction ---


Features and capabilities needed that nothing above can address: