This article has multiple issues. Please help talk page. (Learn how and when to remove these template messages)( or discuss these issues on the Learn how and when to remove this template message)
Netscape Plugin Application Programming Interface (NPAPI) is an application programming interface (API) that allows plugins (more specifically, browser extensions) to be developed for web browsers. It was first developed for Netscape browsers, starting in 1995 with Netscape Navigator 2.0, but was subsequently adopted by other browsers.
In NPAPI architecture, a plugin declares content types (e.g. "audio/mp3") that it can handle. When the browser encounters a content type it cannot handle natively, it loads the appropriate plugin, sets aside space within the browser context for the plugin to render and then streams data to it. The plugin is responsible for rendering the data. The plugin runs in-place within the page, as opposed to older browsers that had to launch an external application to handle unknown content types.
NPAPI requires each plugin to implement and expose approximately 15 functions for initializing, creating, deleting and positioning plugin content. NPAPI also supports scripting, printing, full-screen plugins, windowless plugins and content streaming.
LiveConnect was used in Netscape 4 to implement scriptability of NPAPI plugins.
The Open Java Interface-dependent implementation of LiveConnect was removed from the Mozilla source code tree in late June 2009 as part of the Mozilla 2 cleanup effort. It is no longer needed with the release of a redesigned Java Runtime Environment from Sun Microsystems. However the old implementation was restored for Gecko 1.9.2, as Apple had yet to port the newer JRE over to Mac OS X.
The disadvantage of LiveConnect is that it is heavily tied to the version of Java embedded within the Netscape browser. This prevented the browser from using other Java runtimes, and added bloat to the browser download size since it required Java to script plugins. Additionally, LiveConnect is tricky to program: The developer has to define a Java class for the plugin, run it through a specialized Java header compiler and implement the native methods. Handling strings, exceptions and other Java objects from C++ is non-obvious. In addition, LiveConnect uses an earlier and now obsolete application programming interface (API) for invoking native C++ calls from Java, called JRI. The JRI technology has long since been supplanted by JNI.
Full privileges are only granted by default to chrome scripts, i.e. scripts that are part of the application or of an extension. For remote HTML/XHTML/XUL documents, most XPCOM objects are not accessible by the scripts as they have limited privileges due to security reasons. Even if they are accessible (e.g. the XMLHttpRequest object), the usual security restrictions can also be found (e.g. cannot open URLs of other domains).
Mozilla was already using XPCOM to define the interfaces to many objects implemented in C++. Each interface was defined by an IDL file, and run through an IDL compiler that produced header files and a language-neutral type library that was a binary representation of the interface. This binary described the interface, the methods, the parameters, the data structures and enumerations.
XPConnect has no Java dependency. However, the technology is based on XPCOM. Thus the plugin developer must be familiar with reference counting, interfaces and IDL to implement scripting. The dependency on XPCOM led to certain dynamic linking issues (e.g. the fragile base class problem) which had to be solved before the plugin would work correctly with different browsers. XPCOM has since been changed to supply a statically linked version to address such issues. This approach also requires an .xpt file to be installed next to the dynamic-link library (DLL); otherwise the plugin appears to work, but the scripting does not, causing confusion.
At the end of 2004, all major browser companies using NPAPI agreed on NPRuntime as an extension to the original NPAPI to supply scripting, via an API that is similar in style to the old C-style NPAPI and is independent of other browser technologies like Java or XPCOM. It is only supported by Firefox ESR (Extended Support Release) and Safari.
The following web browsers support all NPAPI plugins:
Because of the age of the API, security issues, and adoption of alternative technologies such as HTML5, major web browser vendors began to phase out NPAPI support in 2013.
The following is a list of NPAPI-based plugins:
Internet Explorer and browsers based on Internet Explorer use ActiveX controls, ActiveX documents and ActiveX scripting to offer in-page extensibility on par with NPAPI. Although commonly associated with Internet Explorer, ActiveX is integration technology that allows any computer program to integrate parts of other computer programs that support such integration. Internet Explorer, however, is discontinued and its replacement, Microsoft Edge, does not support ActiveX.
On 12 August 2009, a page on Google Code introduced a new project, Pepper, with the associated Pepper Plugin API (PPAPI); PPAPI is a derivative of NPAPI aimed to make plugins more portable and more secure. This extension is designed specifically to ease the implementation of out-of-process plugin execution.
In February 2012, Adobe Systems announced that future Linux versions of Adobe Flash Player would be provided only via PPAPI. The previous release, Flash Player 11.2, with NPAPI support, would receive security updates for five years. In August 2016, Adobe announced that, contrary to their previous statement, it would again support the NPAPI Flash Player on Linux and keep releasing new versions of it.
Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your IT knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.