< Previous PageNext Page >

Hide TOC

About Web Browser Plug-ins

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, Macromedia 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

Netscape-style plug-ins are written using a cross-platform C API and can be compiled in Mac OS X into either native Mach-O or classic PEF format. Though the API currently 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, Netscape plug-in API s will continue to support the Mach-O format; no such guarantee can be maintained for plug-ins compiled in the PEF 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.

The original Netscape plug-in architecture was integrated into Netscape 2.0 in 1996. Since then, the API has since 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 new 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.

WebKit–Based Plug-ins

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.

What Kind Of Plug-in Should I Develop?

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.

Otherwise, using the WebKit–based plug-in architecture is probably the right plan for you. You will save lots of development and debugging time, and your total lines of code will be much lower than for a Netscape plug-in. However, you will be able to deploy these plug-ins only on Mac OS X, for applications that use the WebKit framework (including Safari).

Registering Your Plug-in

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).

Listing 3 Name That Plug-in

<key>WebPluginName</key>

    <string>WebKit Movie Plug-in</string>

Installing Your Plug-in

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.

Deploying Your Plug-in

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.