Developer Hub

Back in May, we posted about our plans for a developer-focused website in response to feedback we received from add-on developers. The new Developer Hub has something for everyone — whether you’re just getting started or have already made twenty add-ons.

New documentation features of the Hub include:

• Getting Started – an introduction to add-on development with links to important resources
• How-to Library – tutorials, articles, videos, and walk-throughs on add-on development topics
• API & Language Reference – official API and language references
• Case Studies – stories of successful Firefox add-ons
• Add-on Policies – all of our add-on policies in one up-to-date location
• Search – search the best add-on development resources in one place: documentation, forums, newsgroups, reputable blog posts, and more

We’ve also introduced some new tools, with more planned for the coming months:

• Add-on Builder – auto-generate add-on packaging by entering basic information and picking UI parts
• Add-on Validator – add-ons can now be validated even if they’re not hosted on AMO

One of the most important goals of the new Hub is to bring the add-ons community closer together. With that in mind, the Hub features:

• Add-ons Forum – interact with other add-on developers and get help
• Newsletter – about:addons is our monthly newsletter
• Developer News & Promos – relevant news and important information is now prominent throughout the Hub
• Upcoming Events – find out when an add-on event is coming to your area

Developer Tools & News Feed

The tools developers use to submit and manage their add-ons on addons.mozilla.org are now part of the Developer Hub, and we’ve added a cool new way to stay up to date with what’s happening with your add-ons: the add-on news feed.

Any time something of note happens to an add-on, it is recorded in the news feed for the developer to see. This includes developer and editor actions like editing an add-on, submitting a new version, and approving a new version, but also includes user actions such as reviews and collections.

The news feed is available via RSS for one or all of your add-ons.

Search Revamp

As part of this release, we’ve also re-worked our AMO search engine from scratch to provide much more accurate results. This is a huge and much anticipated improvement, and will be covered in detail in a separate blog post.

A big thanks goes to everyone who made this release possible, from the developers, testers, and designers to those who helped review documentation and content.

ShareThis

Collections Phase II

We’ve had over 27,000 collections created and 6.5 million add-on downloads from those collections since the launch on June 10. We want to add a number of new collection features to the website and Add-on Collector extension, including:

• collection ratings
• statistics dashboard for collection creators
• add-on recommendations based on collection data
• recently viewed collections
• Thunderbird & Fennec support for the Add-on Collector

Check out this spec for all the details planned for this second phase. If you have feedback on this, please post it in this newsgroup thread. The website features above are included in AMO 5.0.9, which should be released at the end of next week.

Add-on Developer Hub

In May, we posted about our plans for a new one-stop-shop for add-on developers. Whether you’re someone new to Firefox and not sure if you want to write an extension, a long-time developer looking to stay up-to-date on add-on news and documentation, or an add-on author wanting to update your AMO listings, the Add-on Developer Hub at AMO will be the place to go.

Among the features of the new developer area are:

• add-on case studies
• AMO policies
• how-to library/portal
• API/Language reference links
• add-on builder (extension skeletons with working UI components)
• add-on validator

You can see some mock-ups of what the new site will look like here, or view the spec for all the details. Please post any feedback in this newsgroup thread. We’re planning this for AMO 5.1, which should be released in late September.

Disclosure of Add-on Practices

Many add-on authors, individuals and companies alike, invest large amounts of time and effort into their add-ons, and wish to be compensated for their work. Although we have launched the Contributions feature for authors to accept donations from users, some authors have partnered with companies to support the continued development of their add-on in exchange for the add-on making certain changes to Firefox. We enacted a No Surprises policy in an effort to protect user choice, but unfortunately continue to find surprises.

We feel it is necessary for users to know about certain add-on practices that an add-on employs prior to installation. These practices must be disclosed in a clear and consistent way across AMO. Our plan for this is described in this spec. Please post any feedback in this newsgroup thread.

Add-on Compatibility Reporter

New versions of Firefox are always in the works, and the lead-up to a final release can be hectic for both add-on developers and the AMO team as we try to encourage everyone to test and update their add-ons in the new version. We’ve come up with an idea for an Add-on Compatibility Reporter extension that would be bundled with alpha and beta builds of Firefox and facilitate add-on testing and reporting.

If you have add-ons installed that don’t work, you can report that to AMO. If you have incompatible add-ons installed that work fine, you can report that to us too. We’ll look at all the submitted reports and email developers when we think we know whether the add-on is compatible with that Firefox version, or if it’s not compatible and what problems users are having.

For all the details, you can read the spec. If you have feedback, please post in this newsgroup thread.

As you can see, we have a lot going on, including several projects not mentioned here. Stay tuned to the newsgroup and this blog for the latest on add-ons.

ShareThis

developer.amo will be a site dedicated to add-on developers, rich with documentation, tutorials, and community involvement. With this site, we hope to:

• Give new developers a starting point for creating an add-on
• Give existing developers a place to stay up-to-date on add-on development news, plans, and features
• Make development easier with documentation, tutorials, and examples all in one place
• Build a community of add-on developers to promote an exchange of ideas

From this one site, it should be possible for someone brand new to Mozilla add-on development to:

• find out why they would want to build a Firefox extension by reading case studies
• see examples of how add-ons work
• learn how to make a basic extension, and how to build that extension out into what they want
• get support when they have questions
• upload their add-on to AMO and have it accepted the first time (because policies will be readily accessible and easy to understand)

We’ve come up with an initial featureset we think will go a long way towards improving the developer experience, but would like input from the community before we get started. You can see our list of initial ideas on our wiki.

If you have thoughts on these features or other ideas, please let us know on the AMO newsgroup.

Edit: There seems to be some confusion about the relationship of this proposed site to MDC. As described in the wiki page above, there will be no new documentation hosted on this site. Rather, it will aggregate/link to existing documentation available on MDC and other resources. Any new documentation written as part of this site will still be hosted on MDC. developer.AMO will serve as a portal between AMO and add-on documentation, of which many articles are available on MDC.

ShareThis

Grok extensions, set up your development environment, and make your first one. We’ll explain how extensions integrate into Firefox and what they can do, show you how to set up an environment to ease their development, and walk you through the making of a simple “Hello World!” extension. Bring your laptop and prepare to follow along. By the end of this session, you’ll be an extension developer.

Extension Bootcamp (Mozilla Labs Design Challenge: Spring 09) from Mozilla Labs – Concept Series on Vimeo.

Now combine the video with Robert Nyman’s step-by-step add-on tutorial and the newly released Firefox Add-ons Developer Guide and you’ll be well on your way to honing your add-on development skills.

ShareThis

Firefox Add-ons Developer Guide – beta release

It’s with  great excitement that we  announce today the beta  release of the Firefox Add-ons Developer Guide. This  guide, is based on an earlier tutorial written and printed for  an Add-ons conference organized by our colleagues in Japan back in June 2007,  and has now been updated for the Firefox  3.5  release.  The  document  will  guide  and  assist  add-ons aficionados around the world, eager to develop their own Firefox add-on. Its catered  to all types  of user,  from the experienced  developer who needs a little push in the right  direction, to the new beginner keen to get his hands dirty, but not sure where to begin.

The content of the guide

The guide is divided into 6 chapters and one appendix:

Top page

1. Introduction to extensions
2. Technologies used in developing extensions
3. Introduction to XUL: How to build a more intuitive UI
4. Using XPCOM: Implementing advanced processes
5. Let’s build a Firefox extension
6. Firefox extensions and XUL applications
7. Appendix: What you should know about open-source software licenses

State of the document

As  described, this  is a  beta  version of  the document.  The text  of the  guide has  been  thoroughly revised,  and is  now  open to  further contributions, corrections  and modifications. Paul Rouget  of Mozilla’s evangelism  team  is coordinating  the  project  and will  be  regularly reviewing  and integrating  contributions from  the community.  Feedback will be incorporated, ready for final release a few weeks before Firefox 3.5.

How to contribute

If you  would like to  help, first, please  read through the  task list. The guide is hosted on MDC, which is a wiki, so feel free to add content and fix mistakes. If you would  like to provide comments and suggestion, or if you want to ask questions, please do so through the MDC forum.

If you would like to propose a deep modification, please, first, discuss it via the forum.

Thanks

Thanks a lot to the original authors:

• Hideyuki Emura
• Hiroshi “Piro” Shimoda
• Taiga Gomibuchi
• Taro Matsuzawa
• Yutaka Kachi

… and Erwan Loisant, Andrew Williamson and Brian King for their useful reviews.

The license of the guide is Attribution-Share Alike 2.1 Japan.

Calling all Add-on Developers!

Mozilla Add-ons developers out there, if  you would like to help improve

this guide  and make it become  “the” reference for those  interested in developing a Firefox  add-on, take a peek  at the guide, drop  us a line and tell us  what you would change, add, delete  or improve. The Firefox Add-on Developer Guide will always be a work in progress, so please help

improve it today !

ShareThis

Reposted with permission from Robert Nyman:

Admit that you have always wanted to know how to develop a Firefox extension but never had the time to learn. Here I will walk you through and at the end of the article we will have created a fully functional Firefox extension!

Our objective

We will create a Firefox extension to find all links in the current web page, highlight those which have a target attribute and alert you how many links it found. The good part is that once you have done this, you have both an understanding of Firefox extension development as well as a blueprint for any extension you would want to develop in the future.

What you need – setting up the developing environment

First, let’s start with setting up your development environment. You need Firefox (duh) and basically whatever code editor you prefer. Then, there are some recommended things to do to prepare Firefox:

Create a different development profile

The first step is to create a different profile in Firefox, since you will do some settings and changes that you probably don’t want for your regular profile. In my case, I’ve created a new development profile named “dev”. The steps to do this are:

Profile manager on Windows

Open the Windows Start menu and choose the Run option (on Vista, it might not be there – just press Windows key + R in that case). In the run dialog, write firefox -P and press enter/click OK. Choose Create Profile in the dialog and follow the steps.

Profile manager on Mac

Open the Terminal (located under /Applications/Utilities) and type in /Applications/Firefox.app/Contents/MacOS/firefox -profilemanager. Choose Create Profile in the dialog and follow the steps.

Profile manager on Linux

Open a terminal, use CD to navigate to your Firefox directory and then enter ./firefox -profilemanager. Choose Create Profile in the dialog and follow the steps.

Configuration settings for Firefox

Open Firefox through the Profile Manager (process described above, or set the development profile as default during extension development). Then enter about:config in the address bar. It will warn you about changing settings, but it’s ok since what you will do is only minor changes for development. You can filter the existing settings, and if any of the below settings don’t exist, you can just create them.

Recommended settings

These are good to enable extension errors in the Firefox Error Console (Tools > Error Console), disable XUL caching and such.

• javascript.options.showInConsole = true
• nglayout.debug.disable_xul_cache = true
• browser.dom.window.dump.enabled = true

Optional settings

These aren’t necessary, but they might help you out. Personally, I don’t use these.

• javascript.options.strict = true
• extensions.logging.enabled = true

Point your Firefox extensions directory to your extension

Instead of constantly preparing and reinstalling your extension, there’s a simple way to add a pointer from your Firefox extensions directory to your code location. To do this, you must first find your profile directory:

Find your profile directory

The profile directory is where you will find all the settings for your Firefox profiles, including extension information.

Find profile directory on Windows

In Windows 2000 and XP, open Explorer and go to C:\Documents and Settings\[your user name]\Application Data\Mozilla\Firefox\Profiles and in Vista, go to C:\Users\[your user name]\AppData\Roaming.

Find profile directory on Mac

Open the Terminal and type in CD ~/Library/Application\ Support/Firefox/profiles/. There you will find your Firefox profiles, and they will be named with letters and numbers, followed by a dot (.) and then your profile name, e.g. 12a3bc4d.dev.

Find profile directory on Linux

Open a terminal and type in CD ~/.mozilla/. In that location, you will find all your Firefox profiles, and they will be named with letters and numbers, followed by a dot (.) and then your profile name, e.g. 12a3bc4d.dev.

Pointing to an extension

In your development profile folder, you will find a folder named extensions. In it, you will have code for all your installed extensions. Instead of placing your code there, you can create a pointer file. Do that by creating a file with a unique name for you (this will have to be the same as you chose for your em:id value in your install.rdf file – more on that below).

In the case of our example, create a file named linktargetfinder@robertnyman.com, without any extension, and in it just point it to where you will have your code, e.g. C:\extensions\ (Windows) or ~/Sites/linktargetfinder/ (Mac).

Creating folder structure and files

What is needed to have a good base for your extension development, is to create the structure of the extension code. Start by creating this hierarchy:

install.rdf

We begin with the intimidating code of install.rdf. This is where you will have all the meta information about your extension, which versions of Firefox it supports and other assorted information. Our install.rdf will look like this:

<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-RDF-syntax-ns#"
     xmlns:em="http://www.mozilla.org/2004/em-RDF#">

	<Description about="urn:mozilla:install-manifest">
		<em:id>linktargetfinder@robertnyman.com</em:id>

		<em:name>Link Target Finder</em:name>
		<em:version>1.0</em:version>
		<em:type>2</em:type>
		<em:creator>Robert Nyman</em:creator>

		<em:description>Finds links that have a target attribute</em:description>
		<em:homepageURL>http://www.robertnyman.com/</em:homepageURL>
		<em:optionsURL>chrome://linktargetfinder/content/options.xul</em:optionsURL>

		<em:targetApplication>

			<Description>
				<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
				<em:minVersion>2.0</em:minVersion>
				<em:maxVersion>3.1b2</em:maxVersion>

			</Description>
		</em:targetApplication>
	</Description>
</RDF>

Scary, right? Well, even if your not used to RDF it’s not that bad at all. Like most code, there’s some mandatory information that you will never need to change, and then some of your own to sprinkle in. The interesting parts for us are:

In the Description node

em:id

This is where you add your unique developer id, of your own choosing. Note that this has to be the same as the pointer file you created above.

em:name

The name of your extension.

em:version

Current version of your extension.

em:type

The type declares that is an extension, as opposed to, for instance, a theme.

em:creator

Well, you!

em:description

Describes your extension functionality. Will be shown in the Tools > Add-ons window.

em:homepageURL

The URL of your extension’s web site.

em:optionsURL

The URL to where you will have your file for editing options/preferences.

In the Description/em:targetApplication node

em:id

This value is the actual id of Firefox. Change this if you want to develop for Thunderbird or something else.

em:minVersion

The minimum version of Firefox required to run the extension. Valid Application Versions.

em:maxVersion

The maximum version of Firefox required to run the extension. Valid Application Versions.

Read about more options in Install Manifests.

chrome.manifest

The chrome of Firefox is everything around the content window. i.e. web browser toolbar, menus, statusbar etc. The next file for our extension, which will probably feel a bit awkward to edit, is the chrome.mainfest file. This one, however, is in conjunction with install.rdf the key to how your extension will be added to Firefox, and how it will work. Our chrome.manifest file looks like this:

content     linktargetfinder    chrome/content/
content     linktargetfinder    chrome/content/ contentaccessible=yes
overlay chrome://browser/content/browser.xul chrome://linktargetfinder/content/browser.xul

locale	linktargetfinder	en-US	locale/en-US/

skin	linktargetfinder	classic/1.0	skin/
style	chrome://global/content/customizeToolbar.xul	chrome://linktargetfinder/skin/skin.css

So, what are all those options? Let’s go through them:

content linktargetfinder chrome/content/

The path to where your extension content files will be found.

content linktargetfinder chrome/content/ contentaccessible=yes

Same as the above, but when contentaccessible=yes is added, it allows Firefox 3 and later to access the extension’s files and show them in the web browser (like within a web page). Found this excellent help through Web pages accessing chrome:// is forbidden.

overlay chrome://browser/content/browser.xul chrome://linktargetfinder/content/browser.xul

The path to which file you will use to override web browser elements, and add items to the toolbar, menu and statusbar.

locale linktargetfinder en-US locale/en-US/

Used for localization of content.

skin linktargetfinder classic/1.0 skin/

Skin reference.

style chrome://global/content/customizeToolbar.xul chrome://linktargetfinder/skin/skin.css

Style overlays for chrome pages.

More information can be found in Chrome Manifest.

chrome folder

Ok, once the mandatory parts are out of the way, now things start to get interesting. This is also when we start to look at XUL, which stands for XML User Interface Language. It is developed by Mozilla to create interfaces in Firefox, Thunderbird etc.

First, within the chrome/content folder, create three files:

• browser.xul
• options.xul
• linkTargetFinder.js

browser.xul

This is the file we will use to override some of the default look of the web browser, i.e. add a button to the toolbar, an item to the Tools menu and a statusbar icon. Let’s look at the complete browser.xul file and then break it down:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://linktargetfinder/skin/skin.css" type="text/css"?>
<!DOCTYPE linktargetfinder SYSTEM "chrome://linktargetfinder/locale/translations.dtd">
<overlay id="sample" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

		<script src="linkTargetFinder.js" />

		<menupopup id="menu_ToolsPopup">
			<menuitem label="&runlinktargetfinder;" key="link-target-finder-run-key" oncommand="linkTargetFinder.run()"/>
		</menupopup>

		<keyset>

			<key id="link-target-finder-run-key" modifiers="accel alt shift" key="L" oncommand="linkTargetFinder.run()"/>
		</keyset>

		<statusbar id="status-bar">
			<statusbarpanel id="link-target-finder-status-bar-icon" class="statusbarpanel-iconic" src="chrome://linktargetfinder/skin/status-bar.png" tooltiptext="&runlinktargetfinder;" onclick="linkTargetFinder.run()" />
		</statusbar>

		<toolbarpalette id="BrowserToolbarPalette">
			<toolbarbutton id="link-target-finder-toolbar-button" label="Link Target Finder" tooltiptext="&runlinktargetfinder;" oncommand="linkTargetFinder.run()"/>
		</toolbarpalette>
</overlay>

First, there some general XML syntax, then you include your CSS code and set a DOCTYPE for localization. It’s followed by the overlay root element with its Ghostbuster-inspired namespace (developers are truly geeks ).

After that you’re free to write whatever XUL you want, and basically it’s like HTML should’ve been. What I mean with that is that it is filled with basic interface options that can’t be found anywhere in HTML. For a complete overview of what you can do, please read the XUL Reference.

In our code here, we start with adding a menu option to the Tools menu in Firefox, and connect it to a keyboard shortcut:

<menupopup id="menu_ToolsPopup">

	<menuitem label="&runlinktargetfinder;" key="link-target-finder-run-key" oncommand="linkTargetFinder.run()"/>
</menupopup>

<keyset>
	<key id="link-target-finder-run-key" modifiers="accel alt shift" key="L" oncommand="linkTargetFinder.run()"/>
</keyset>

Followed by adding an icon to the Firefox statusbar:

<statusbar id="status-bar">

	<statusbarpanel id="link-target-finder-status-bar-icon" class="statusbarpanel-iconic" src="chrome://linktargetfinder/skin/status-bar.png" tooltiptext="&runlinktargetfinder;" onclick="linkTargetFinder.run()" />
</statusbar>

And at the end, we add a button to the Firefox toolbar:

<toolbarpalette id="BrowserToolbarPalette">
	<toolbarbutton id="link-target-finder-toolbar-button" label="Link Target Finder" tooltiptext="&runlinktargetfinder;" oncommand="linkTargetFinder.run()"/>
</toolbarpalette>

Note that you need to go to View > Toolbars > Customize… to add your button to the visible toolbar.

In the above examples, you might have noticed the &runlinktargetfinder; code. That is used for localizing text, and its translation can be found in the locale folder. More on that later.

Another thing to notice, which can be tricky at first, is that some ids and classes for XUL elements actually have meaning for its display, stemming from core Firefox code. Make sure to read the XUL Reference thoroughly for the elements you’re using.

If you want to use regular HTML elements instead of/together with XUL, you can include the XHTML definition in your root element, and then include any HTML element with the html: prefix. Like this:

<overlay id="sample" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" xmlns:HTML="http://www.w3.org/1999/xhtml">

<html:input type="submit" value="Send" />

options.xul

This file is used for the options/preferences dialog for your extension, and its path is pointed out in the install.rdf file in the Description/em:optionsURL node. The complete options file for our extension looks like this:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<prefwindow
     title="Link Target Finder Preferences"
     xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

	<prefpane label="Link Target Finder Preferences">
		<preferences>
			<preference id="link-target-finder-autorun" name="extensions.linktargetfinder.autorun" type="bool"/>

		</preferences>

		<groupbox>
			<caption label="Settings"/>
			<grid>
				<columns>
					<column flex="4"/>

					<column flex="1"/>
				</columns>
				<rows>
					<row>
						<label control="autorun" value="Autorun"/>
						<checkbox id="autorun" preference="link-target-finder-autorun"/>

					</row>
				</rows>
			</grid>
		</groupbox>	

	</prefpane>

</prefwindow>

Again, some regular XML information and styling of the content. It then uses some XUL to layout the content of the preferences dialog. The interesting part here, though, is connecting the user input to the actual settings for the extension (those settings are to be found in the prefs.js file, mentioned in detail below).

To start with, you create a preferences group in the options.xul file with your desired preferences. Then, give each preference an id and connect it to the extension’s real preferences with the name attribute:

<preferences>
	<preference id="link-target-finder-autorun" name="extensions.linktargetfinder.autorun" type="bool"/>
</preferences>

Then you create an element and add a preference attribute to it, pointing to the before-chosen idattribute for the preference in the preferences group. It will then automatically connect its value to that specific preference.

<checkbox id="autorun" preference="link-target-finder-autorun"/>

Note that you don’t need to add an OK button for the dialog – for instance, on Macs there won’t be one while it’s automatically added for Windows users. All about system compatibility, my friends.

linkTargetFinder.js

If you’re like me, this is where you will feel at home. Good ol’ JavaScript code.

What’s nice here is that you can script any element in the XUL and any element in the HTML content window as well. All you need to access the content window is to precede your document call with the content keyword, like this:

content.document.getElementsByTagName("a");

Here’s the complete code of the linkTargetFinder.js file:

var linkTargetFinder = function () {
	var prefManager = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefBranch);
	return {
		init : function () {
			gBrowser.addEventListener("load", function () {
				var autoRun = prefManager.getBoolPref("extensions.linktargetfinder.autorun");
				if (autoRun) {
					linkTargetFinder.run();
				}
			}, false);
		},

		run : function () {
			var head = content.document.getElementsByTagName("head")[0],
				style = content.document.getElementById("link-target-finder-style"),
				allLinks = content.document.getElementsByTagName("a"),
				foundLinks = 0;

			if (!style) {
				style = content.document.createElement("link");
				style.id = "link-target-finder-style";
				style.type = "text/css";
				style.rel = "stylesheet";
				style.href = "chrome://linktargetfinder/skin/skin.css";
				head.appendChild(style);
			}	

			for (var i=0, il=allLinks.length; i<il; i++) {
				elm = allLinks[i];
				if (elm.getAttribute("target")) {
					elm.className += ((elm.className.length > 0)? " " : "") + "link-target-finder-selected";
					foundLinks++;
				}
			}
			if (foundLinks === 0) {
				alert("No links found with a target attribute");
			}
			else {
				alert("Found " + foundLinks + " links with a target attribute");
			}
		}
	};
}();
window.addEventListener("load", linkTargetFinder.init, false);

While it’s a fair bit of code, it is also very basic. When the window loads, it runs the init method of the linkTargetFinder object. If the preference autorun is set to true, it calls its run method immediately. Otherwise, it will only be called when the toolbar button, menu item or statusbar icon is clicked. This happens through the oncommand attribute on the elements in the browser.xul file.

The code in the run method is pretty straight-forward. It adds a CSS file from the extensions chrome folder to the current document, finds all links in it, loops through them and checks if they have a target attribute, counts those, highlights them and alerts you with the number of hits.

As you can see, there’s a pointer in the code to something called gBrowser. That is how to get a reference to the current web browser, and you could also use getBrowser() as well. Note that this sort of code is only available from within the XUL context of the web browser. More information and options can be found in Tabbed Browser.

The only unusual part for a JavaScript is the variable prefManager, which connects to Firefox preference manager, and later gets the autorun preference with the help of this code:

var autoRun = prefManager.getBoolPref("extensions.linktargetfinder.autorun");

The three types of extension preferences are string, integer and boolean, and the six methods to work with them are:

• getBoolPref()
• setBoolPref()
• getCharPref()
• setCharPref()
• getIntPref()
• setIntPref()

defaults folder

Within the defaults folder, you create a preferences folder and in that one a file named pref.js. This is used for the preferences you want to use for your extension, and looks like this:

pref("extensions.linktargetfinder.autorun", false);

locale folder

Used for localization. In our case here, we just have one child folder for en-US content, but it can be easily extended. That folder has a file named translations.dtd, which contains translations for entities used in XUL files. Our file looks like this:

<!ENTITY runlinktargetfinder "Run Link Target Finder">

Remember &runlinktargetfinder; in the browser.xul file? This is where it gets its translation.

skin folder

Now when we have all functionality in place, let’s make things a little more pretty (just a little, ok?). In our skin folder, we have three files: skin.css, status-bar.png and toolbar-large.png. The images are, naturally, used for the toolbar and statusbar respectively.

The CSS in skin.css is used for setting the image for the toolbar, the size and space for the statusbar icon and the highlight look of links with a target attribute. The code looks like this:

#link-target-finder-toolbar-button {
	list-style-image: URL("chrome://linktargetfinder/skin/toolbar-large.png");
}

#link-target-finder-status-bar-icon {
	width: 83px;
	margin: 0 5px;
}

.link-target-finder-selected {
	outline: 2px solid red !important;
}

Packaging and installing

Firefox extensions are delivered like XPI files, and those are basically just ZIP files with another extension. Therefore, when you’re finished with your extension, all you need to do is ZIP your files together and give it an XPI extension. Note: do not ZIP the containing folder for your extension, just its contents (chrome folder, chrome.manifest and install.rdf files etc).

Once you have your XPI file, you can just drag and drop it into Firefox, and it will automatically install.

Packaging with Windows

Select all the contents of your extension folder, right-click and choose Send To > Compressed (Zipped) Folder. Rename it to .xpi instead of .zip and you’re done!

Packaging with Mac

Open the Terminal, navigate to your extension with the CD command and then type in zip -r LinkTargetFinder.xpi *. Ta daa!

Packaging with Linux

Open a terminal, get to your extension folder, and type in zip -r LinkTargetFinder.xpi * All done!

Distribution of your extension

There are two options of distributing your extension. Either use addons.mozilla.org or host it yourself. If you do it yourself, you can specify an updateURL in your install.rdf file, but note that since Firefox 3 it has to be a secure location, e.g. through SSL or similar.

Personally, I’d recommend addons.mozilla.org for greater reach, auto-update pushing and statistics. The downside of it, though, is that the review process can take quite some time for your extension to get an approval. Before that it can still be downloaded as an experimental add-on, but people need to have an addons.mozilla account and log in to do so.

To make sure it doesn’t take longer than necessary, I recommend reading
Successfully Getting your Addon Reviewed.

Downloads

All the code I’ve created here is available both as a ZIP file of everything, so you can start experimenting, change stuff and see what happens. It is also available as an XPI file, which you can install in your Firefox just to test the functionality (drag and drop it into Firefox).

• Download Link Target Finder code as a ZIP file.
• Download Link Target Finder as an XPI file.

Happy extension developing!

I hope this has been a good, albeit long, introduction to Firefox extension development and that it has helped you to grasp concepts you hadn’t gotten full control over yet. Good luck, and don’t hesitate to ask if you have any questions!

ShareThis

I have been recently asked by couple of developers how to properly design architecture of a Firefox extension. The first thing that immediately came to my mind at that point was a problem with global variables defined by extensions in ChromeWindow scope.

This problem can easily cause collisions among various extensions. Something that should be always avoided (and is also part of AMO review process) since this kind of issues is very hard to find. Yes, global variables are still evil, especially in OOP world.

I don’t want to describe how to develop a new extension from scratch. For this there is already bunch of detailed articles. I am rather concentrating on effective tactics how to make Firefox extension architecture maintainable and well designed.

So, read more if you are interested…

Namespace Architecture

Defining global variables is a way how to risk collisions with other extensions. I think that creating just one global variable per extension that is unique enough (composed e.g. from the name of the extension, domain URL, etc.) is sufficient strategy how to avoid undesirable collisions.

The architecture for namespaces used in Firebug, is based (more or less) on well known module pattern (originally described by Douglas Crockford). It’s really simple and transparent so, I hadn’t understand how it actually works for a long time. I believe other extension developers can utilize this approach as well.

The basic idea is to wrap content of every JS file into its own scope that is represented by a function so, there are no global objects. See following snippet.

This is what I am going to call a namespace.

The first question is how to ensure that the function is actually called and the code executed at the right time. The second question is how to share objects among more files (see Sharing among namespaces chapter below). Firebug solves this by registering every namespace and executing all when Firefox chrome UI is ready. See modified example.

The namespace (regular function) is passed as a parameter to myExtension.ns function. The myExtension object is the only global object that is defined by the extension. This is the singleton object that represents entire extension. Don’t worry if the name is long, there’ll be a shortcut for it (in real application it could be e.g. comSoftwareIsHardMyExtension).

The ns function is simple. Every function is pushed into an array.

Actual execution of registered namespaces (functions) is only matter of calling apply on them.

Now, let’s put all together and see how the global extension (singleton) object is defined and initialized.

The following source code snippet represents a browserOverlay.js file that is included into an overlay (browserOverlay.xul)

As I mentioned above, there is just one global object myExtension.

To summarize, the object implements following methods:

• ns – register a new namespace.
• initialize – initialize all namespaces.
• shutdown – clean up.

And also, the code makes sure that initialize and shutdown methods are called at the right time. This is why event handlers are registered.

The browserOverlay.xul looks as follows now.

And the Module1.js and Module2.js files are both the same.

Sharing among namespaces

Now, when we have our script within a local scope(s), let’s answer the question how to share functionality and data among individual namespaces. The general idea is to use the one global object we have – myExtension.

First of all, see the following source code (lib.js file).

You can see that a new LIB property is created within our global myExtension singleton. This objects represents a library of functions that should be shared among all modules in our extension. At this point, you can also get inspiration from Java Packaging and create whole tree of namespaces within the global singleton (just like e.g. YUI does)

The lib.js file is included in browserOvelay.xul (just after browserOverlay.js)

Let’s also improve our module script a bit.

By utilizing with statement we can simply access all library functions as if they would be a global functions.

In case we want to access our singleton global object we can also utilize theApp shortcut (useful especially if the name is long) as follows:

Here is how the architecture look like from UML perspective.

Download example extension here.

ShareThis