Web browser plug-ins are considered extensions to existing web browsers. By installing them locally on your machine, you can “teach” your web browsers to support alternative content types—perhaps even custom types you design yourself—or to perform additional tasks that a ready-made browser cannot do. For example, Adobe Flash animations are not supported natively by any browsers. By installing their plug-in, though, you expand the capabilities of your browser to accept, interpret, and display the animation directly within the main content view.
The WebKit framework natively supports two different types of browser plug-ins. One is the Netscape-style plug-in, based off a common cross-platform API. The second is the WebKit–based plug-in, developed in Objective-C and supported by all WebKit-based applications.
Netscape-style plug-ins are written using a cross-platform C API. These plug-ins are compatible with a wide range of web browsers.
The original Netscape plug-in architecture was integrated into Netscape 2.0 in 1996. Since then, the API has been adopted by most common web browsers, including Safari. It has built-in support for onscreen drawing, various types of event handling, and networking functions.
In addition to the core plug-in functionality, Apple has extended the capabilities of the Netscape-style plug-ins. Starting with the WebKit framework bundled with Safari 1.3 (on Mac OS X version 10.3) or Safari 2.0 (on Mac OS X version 10.4), the Netscape-style plug-ins can also perform scripting functions.
The Netscape-style plug-in scripting environment allows plug-ins to access scripting languages such as JavaScript (including accessing script elements such as a web page’s Document Object Model). It also allows scripting languages to access and control elements of the plug-in.
In Mac OS X v10.5 and earlier, Netscape-style plug-ins can be compiled in Mac OS X into either the Mach-O or PEF (CFM) binary format (although CFM is PowerPC-only). Beginning in Mac OS X v10.6, Netscape-style plug-ins should be updated to use a 64-bit binary to work with 64-bit instances of Safari or other WebKit clients. To do this, they must be built as 32/64-bit multi-architecture binaries using the Mach-O file format.
Though the API supports both formats, Mac OS X natively supports the Mach-O style, and you will find that your plug-in will run much faster if compiled as a Mach-O binary. In the future, WebKit will continue to support Netscape plug-ins built with the Mach-O format; no such assurance can be given for plug-ins compiled in the PEF (CFM) format. You can also develop and debug Mach-O plug-ins in Xcode, but not PEF plug-ins. Once compiled, the plug-ins can be installed and used in most web browsers.
WebKit-based plug-ins are written using Objective-C API that is unique to WebKit. Although the API is not cross-platform, any plug-in created in this fashion can be used in Safari and all other WebKit-based applications. This style of plug-in is easy to develop and significantly cuts down on the amount of code you have to write, because it harnesses all the premade API and interface technology available to Cocoa applications.
Because WebKit-based plug-ins are based on subclasses of Cocoa’s NSView, this style also offers support for onscreen drawing and event handling.
Apple has also provided these types of plug-ins with access to the enclosing scripting environment; a script can call methods and read properties from the plug-in, and vice versa.
When you create a WebKit-based plug-in you need to compile it as a universal binary. For more information, see Universal Binary Programming Guidelines, Second Edition.
Because the WebKit framework provides for two different and distinct plug-in technologies, you may be asking yourself, what technology should I use?
You should use the Netscape-style plug-in architecture if:
Your plug-in needs to be supported on multiple Mac browsers, not all of which use the WebKit framework.
Your plug-in will be deployed on multiple platforms. Because the API is cross-platform, you would just have to compile the same code for Windows or Linux.
With the WebKit–based plug-in architecture, you will save on development and debugging time, and your total lines of code will be much lower than for a Netscape plug-in. However, you can deploy these plug-ins only in applications that use the WebKit framework (including Safari) on Mac OS X. They are not compatible with other browsers, nor with Safari on Windows.
Your plug-in will need to register itself with the application that uses it, so that the application knows what content types you support. Your plug-in bundle needs to contain this important registration information. In addition to setting the correct registration information for your plug-in, you must set the correct CFBundlePackageType. The default CFBundlePackageType when you create a new WebKit plug-in in Xcode is BNDL, this must be changed to WBPL to be recognized by WebKit.
There are two different ways of storing this registration information. One is with an Info.plist file stored within the plug-in bundle. This is an easy-to-edit and easy-to-maintain way to register your content types, but is supported only by applications based on the WebKit (no matter in what style you wrote the plug-in). The other way to register the information—and this method is required if you want other browsers on the Mac platform to support your plug-in—you also have to include a Carbon resources file.
The Info.plist file contains important information. Let’s use an example from the WebKit movie plug-in, which you will create in “Creating Plug-ins with Cocoa and WebKit .” First, you need to register a description of the plug-in (see Listing 1).
Listing 1 Plug-in description in the Info.plist file
<key>WebPluginDescription</key> |
<string>Simple WebKit plug-in that displays movies</string> |
Next, you’ll need to register the MIME types that your plug-in supports (see Listing 2).
Listing 2 Registering MIME types in the Info.plist file
<key>WebPluginMIMETypes</key> |
<dict> |
<key>video/x-webkitmovie</key> |
<dict> |
<key>WebPluginExtensions</key> |
<array> |
<string>mov</string> |
</array> |
<key>WebPluginTypeDescription</key> |
<string>QuickTime Movie</string> |
</dict> |
</dict> |
Finally, your plug-in needs a useful name for the application to call it by (see Listing 3).
<key>WebPluginName</key> |
<string>WebKit Movie Plug-in</string> |
Plug-ins can be stored in one of two places on a Mac OS X system:
Plug-ins stored in /Library/Internet Plug-ins can be shared by all users on the computer.
Plug-ins stored in ~/Library/Internet Plug-ins will be available only to the user whose home directory contains them.
In addition, the WebKit-based plug-ins can be stored inside the bundle of any application that uses the WebKit, by storing it in:
AppName/Contents/Plug-ins |
where AppName is the actual application’s executable bundle.
Plug-ins are generally reloaded on each application start.
Content that your plug-ins will view needs to be embedded within HTML. Most browsers do this with an EMBED tag, but others require the OBJECT tag. For maximum compatibility, you can tune your page to support both. The example in Listing 4 is specific to the QuickTime plug-in provided by Apple, and you can tune these parameters to your own mode of business.
Listing 4 Embedding a movie into an HTML page
<OBJECT CLASSID="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" |
WIDTH="160" |
HEIGHT="144" |
CODEBASE="http://www.apple.com/qtactivex/qtplugin.cab"> |
<PARAM name="SRC" VALUE="sample.mov"> |
<PARAM name="AUTOPLAY" VALUE="true"> |
<PARAM name="CONTROLLER" VALUE="false"> |
<EMBED SRC="sample.mov" |
WIDTH="160" |
HEIGHT="144" |
AUTOPLAY="true" |
CONTROLLER="false" |
PLUGINSPAGE="http://www.apple.com/quicktime/download/"> |
</EMBED> |
</OBJECT> |
The variables for the Active X controls will change based on your plug-in’s behavior. Read Apple’s HTML Scripting Guide for QuickTime tutorial for more information.
Last updated: 2009-03-13