NPAPI

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Netscape Plugin Application Programming Interface (NPAPI) is a cross-platform plugin 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") 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, destroying and positioning plugin content. NPAPI also supports scripting, printing, full-screen plugins, windowless plugins and content streaming.

History[edit]

The creation of NPAPI was motivated by Adobe Systems. John Warnock, CEO of Adobe, and Allan Padgett, one of the primary authors of Acrobat Reader, were hopeful that Adobe's fledgling Portable Document Format (PDF) file format could play a role beyond the desktop. Soon after Netscape released the first version of Navigator, Padgett and fellow developer Eswar Priyadarshan tried to find a way to make PDF an integral part of the Web experience. The result was a live demo shown to Warnock and Netscape CEO Jim Clark. Prior to that demo, the only native file formats on the Web were HTML pages and embedded images. Links to other file types caused the user to be prompted to download the file, after which the user could open the appropriate application. In that demo, however, when a user clicked on a link to a PDF file, the file was rendered within the browser window, seamlessly blending HTML and PDF consumption. Clark excitedly asked who at Netscape had provided support for the integration, only to discover that the integration was done without Netscape involvement, but by reverse engineering the Netscape browser.

The companies set out the next week to bring what was known as "Allan's Hack" to market. While Netscape was ready to incorporate PDF directly into the browser, and certainly Adobe would have gained from that, Padgett proposed his plugin architecture. Adobe developers Gordon Dow and Nabeel Al-Shamma had recently added a plugin architecture to the Acrobat Reader to leverage the development efforts of developers outside of the Reader team. Padgett had been a part of that effort, and he expected that if given a chance, other companies (and hopefully teams within Adobe) would choose to extend the Web as well. Clark and team in the end were convinced and set off designing the API that would support the new model.

In the following years, other web browsers (see § Browser support) adopted NPAPI.

Scripting support[edit]

Scripting is a feature allowing JavaScript code in a web page to interact with the plugin. Various versions of Netscape and then Mozilla supported this feature using different technologies, including LiveConnect, XPConnect, and NPRuntime.

LiveConnect[edit]

Main article: LiveConnect

With Netscape 4, NPAPI was extended to allow plugins to be scripted. This extension is called LiveConnect. A plugin could implement a Java class and expose an instance of it. The class could be called from JavaScript and from Java applets running within the page.

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.

XPConnect[edit]

Main article: XPConnect

LiveConnect was problematic for Mozilla. The dependency on an obsolete and proprietary Java runtime and the JRI API meant that LiveConnect never really worked.

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 uses the type library information to marshal calls between different thread contexts and between JavaScript and natively compiled C++. XPConnect is used extensively throughout Mozilla. Starting with Netscape 6.1 and Mozilla 0.9.2, NPAPI was extended, so that a plugin could return a scriptable interface to itself and XPConnect would marshal calls to it from JavaScript and the C++ implementation.

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.

NPRuntime[edit]

At the end of 2004, all major browser companies using NPAPI agreed on NPRuntime[1] 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 supported by Mozilla (1.7.5+), Firefox, Safari, Opera and Chrome.

Browser support[edit]

The following web browsers support NPAPI plugins:

The following browsers once supported NPAPI plugins, but have dropped support since:

  • Google Chrome and Chromium:[3] In September 2013, Google announced that it would phase out NPAPI support in Chrome during 2014 because "NPAPI's 90s-era architecture has become a leading cause of hangs, crashes, security incidents, and code complexity".[4] NPAPI support was removed from the Linux version of Chrome 35 and later, in May 2014.[5] Since April 2015, on Chrome for Windows and OS X versions 42 and later, NPAPI support is disabled by default but can be turned on in the settings. Google has dropped Chrome NPAPI support from all platforms in Chrome 45, scheduled for stable release in September 2015.[6]
  • Internet Explorer: NPAPI was supported in Internet Explorer versions 3 through 5.5 SP2, allowing plugins that functioned in Netscape Navigator to function in Internet Explorer. Support came via a small ActiveX control (named "plugin.ocx") file that acted as a shim between ActiveX and the NPAPI plugin. However, Microsoft dropped support in version 5.5 SP2 and later for security reasons.[7][8][9][10]
  • Opera: NPAPI support is deprecated from Opera 20 onward. NPAPI support for Linux was removed with Opera 24.

Similar technologies[edit]

ActiveX[edit]

Main article: ActiveX

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 notoriously associated with Internet Explorer, ActiveX is integration technology that allows any computer program to integrate parts of other computer programs that support such integration.[11] Internet Explorer, however, is discontinued and its replacement, Microsoft Edge, does not support ActiveX.

PPAPI[edit]

On 12 August 2009, a page on Google Code[12] introduced a new project, Pepper, with the associated Pepper Plugin API (PPAPI);[13] PPAPI is a derivatiation of NPAPI aimed to make plugins more portable and more secure.[14] This extension is designed specifically to ease the implementation of out-of-process plugin execution. The goals of the project are to provide a framework for making plugins fully cross-platform. Topics considered include:

  • Uniform semantics for NPAPI across browsers.
  • Execution in a separate process from the renderer/browser.
  • Standardize rendering using the browser's compositing process.
  • Defining standardized events and 2D rasterization functions.
  • Initial attempt at providing 3D graphics access.
  • Plugin registry.

Google Chrome, Chromium[15] and Opera (since version 24[16]) support PPAPI.

On 26 May 2011, Mozilla announced that it was "not interested in or working on Pepper at this time."[17]

In February 2012, Adobe Systems announced that future Linux versions of Adobe Flash Player would only be provided via PPAPI, although the previous release, Flash Player 11.2, with NPAPI support, would receive security updates for five years.[18]

See also[edit]

References[edit]

External links[edit]