Development:Porting or Using Firefox Extensions with Camino

Camino has had limited support for UI-less Gecko platform (“Firefox”) extensions for some time; for instance, in the Camino 0.x era, the third-party preference pane “CamiFlash” offered a Flash-blocking feature that used the Flashblock extension.

Camino 2.1 added new features that may allow more extensions to work with Camino; however, as before, several caveats apply.

As a general rule, extensions that have no UI (other than perhaps a toolbar button to toggle behavior on or off) and are implemented largely as JavaScript XPCOM components or XBL bindings to web content, or extensions that have already been ported to Safari or Google Chrome, are most likely to work, or to easily be made to work, in Camino 2.1.

Non-exhaustive list of extension-related differences between Camino and Firefox

• No XUL

  Camino is an embedding application; it embeds the Gecko rendering engine, and a certain amount of the Mozilla platform relevant to core web browser features, inside a native Cocoa application. Camino does not use XUL for the browser’s user interface, and XUL in the content area does not work. Any extension that relies on overlaying browser.xul will not work (or will require changes).

  Extensions that require UI for configuration will need a Camino preference pane to allow the user to change Gecko preferences from Camino, or the user will have to edit the Gecko preference files directly.

• No Firefox-specific functions and libraries

  Camino does not have a browser.js, FUEL, or any other Firefox-specific code or code wrappers/shortcuts. If an extension talks to Gecko using Gecko APIs, there is a decent chance it will work, but anything that relies on Firefox code (e.g., finding the XUL <browser> element or talking to the tabbrowser JavaScript object) will not work (or will have to be rewritten).

• No Extension Manager or extensions system

  Camino does not include the Extensions Manager or a formal extensions system. Camino 2.1 does register (JavaScript) XPCOM components from the profile’s components folder at startup, and it also registers chrome from the profile’s chrome folder at startup. (In addition, Camino 2.1 will load NPAPI plug-ins from the profile’s Internet Plug-Ins folder, allowing for the installation of plug-ins that only Camino will use.) As a consequence, many Firefox extensions that do work in Camino must be unpacked and manually installed, and any updates must also be manually downloaded and installed.

  Since the chrome folder is shared, renaming chrome.manifest to extension.manifest will prevent multiple extensions from clobbering each other’s chrome registration directives.

• Camino 2.1 uses Gecko 1.9.2

  Camino 2.1 uses Gecko 1.9.2, the same version of Gecko used by Firefox 3.6.x, with all of the same Gecko requirements and limitations (e.g., old-style XPCOM registration boilerplate).

Non-exhaustive list of extensions known to work in Camino 2.1

• Universal Behavioral Advertising Opt-out, v1.0

  Sends the “Do Not Track” HTTP header to websites

  • Installation instructions: Unpack the extension and install the universal.js file in your Camino profile’s components folder, then launch Camino.
  • Test page

• Google Analytics Opt-out Browser Add-on (BETA), v0.9.5

  Tells Google Analytics not to track your visits

  • Installation instructions and test page

• Certain content-blocking tools
  • Attachment 573330 on Bug 656584 illustrates how to convert a simple BlockSite script into a JavaScript XPCOM component that Camino 2.1 can use.