By small in the title, I mean small devices. One large step was taken in the Fennec add-ons ecosystem over the weekend at the Mozilla/Maemo get together in Copenhagen [pictures, tweets]. Present were a large chunk of the Fennec developement team, add-on developers, localisers, and community members. We shared the space with Maemo developers and community members, and while there was not much overlap during sessions and hacking, there were some useful discussions on how we can work better together. The weekend was a mix of sessions and hacking, with the focus more on the latter. We ported add-ons, made new ones, found bugs, and had discussions on best practices and ways to improve the user experience. Here is a mini-report of what went down, from an add-ons perspective.

Target

It might be obvious to say this, but Fennec add-ons are much different beasts than their desktop counterparts. All the goodness of the Mozilla Platform is there and available to use, but the UI is completely different. Less hooks are available simply because there is less space, but the design and UI flow provide different challenges. Sure, there are toolstrips, aka vertical bars to stick icons on to, but what would happen if every extension did that. Pretty soon yours would be lost in the mix.

Madhava Enros did a good job of explain the design behind the Fennec UI. Dialogs and context menus are just 2 things among others that are out in Fennec, and their usage is strongly discouraged. With regard to dialogs, one concern I was hearing from devs is how to show preferences. Recent builds of Fennec (get desktop builds here, or ask on irc.mozilla.org#mobile) have already taken steps to address this.

Fennec Add-ons Manager

So as you can see, when Options is selected, the UI appears inline and not in a dialog. While there are still bugs, it is clever, but is it scalable for larger pref sets? Or should extension authors scale down?

Stepping Back

I started off my talk about porting existing extensions [Slides: PDF | PPT] by challenging authors to really think whether they should do it. Ask yourself, does it make sense in this context? Does it fit into the browsing habits of users of smaller devices, which is different than desktop usage? For example, users on the go want more information suggested to them as opposed to go hunting for it which can be cumbersome. Now I don’t want to discourage you from porting your add-on. We certainly need more. Keep in mind that it will be more work than just adding Fennec as a target application in install.rdf, and while doing it, get inspiration for new ideas. I think some of the best add-ons will be ones built from the ground up that take advantage of device capabilities such as GPS and voice.

The document story needs to get better. Mark Finkle posted last week about his documentation efforts so far, and thanks to Mark for that. It gives us a solid foundation to add more. I urge everyone working in this area to post your finding on the Mozilla wiki / Devmo / your blog / anywhere to make life easier for those who follow and help promote adoption. I’ll be personally following up with all participants to make sure they do so.

The Winners

Before the event, we offered a challenge at short notice on Mozdev to developers to propose ports of their existing work or new add-ons for Fennec. 4 entrants got to go to Copenhagen. The winners were (in no particular order):

1. Fabrice Desre – Develop a “local guide” application leveraging the geolocation support in recent Fennec builds. The geoguide will show informations relevant for the user, like touristic information, photos, retaurants and hotel etc. using various data sources such as flickr and dbpedia. The focus here is not to rely on a cluttered map display, but to provide a clean UI : in the same spirit of the experiments going on for the “new tab” in Firefox, but for a “new place”.
2. Chris Neale – Port Link Widgets to Fennec.
3. Marien Zwart – Port RadialContext-mz to Fennec.
4. Benoit Bailleux – autoOpenID looks for OpenID sign-in forms and (depending on its configuration) can log-in automaticaly (or propose to) with no more than one click.

Of the four, Fabrice completed GeoGuide, Chris is almost complete, and Marien and Benoit are still working on it.

GeoGuide determines your location using the Geolocation API, and with that data present you with a map view, weather, local events, images, and wikipedia articles.

And The Rest

Some other good work came out the weekend.

• Nicolas Belloni and Mattias Rost are working on Detector which is their own words, “is an add-on to bring more fingerfriendliness to the content of webpages on Fennec. We strongly support Mozilla’s effort to make a browser adapted for mobile users. So we are aiming at adding more interaction to phone numbers, addresses and contacts’ names. The type of interaction style that we add to the content needs to be thought in order not to be destructive and to take into account the lack of contextual menu. To begin with, we want to detect phones numbers and give the possibility to users to call, save or sms this number”.
• Jesper Hansen is working on a few things — The first is Save Image. Since Fennec has no possibility to save images, then this addon will provide a list of all images on the loaded page with name, ext, size and a single button to save it. Save Image will also provide a simple canvas dialog (or alternative) that slides up from the bottom of the screen when a onmousedown is being detected for longer than a specific time on an image. Second up, Toastercat: an add-on to monitor and display content of icanhascheezburger.com (and friends, see https://addons.mozilla.org/en-US/firefox/addon/11945) RSS feeds in a simple way without having to load the entire page but only rely on the content provided in the feed. A third add-on is related to about:config since Fennec is missing some features there.
• Fabrice followed up the excellent GeoGuide with the equally excellent GrafiTwit. This brings a new twist to tweeting, allow you to doodle on a canvas, send the picture off to Twitpic, and post the link to your stream.
• I ported Zemanta, a few hours of effort, and it now works as the desktop version bar a couple of bugs related to the icon in the location bar. Let me know if you want to try it out, it is not public yet.

Zemanta on Fennec

There are a few more add-ons for Fennec available on Mozilla Add-ons. UPDATE: More than a few.

Lessons Learned and Bugs

One of the lessons learned is best summed up by the mantra ‘performance, performance, performance’. Things you take for granted on the desktop may bite you on the mobile device. Here are some performance related guidelines. Another important point is to try if at all possible to test on one of the mobile devices that Fennec runs on. When testing existing add-ons on Nokia developer devices, it was apparent quickly that this was not done for some existing ones. The desktop versions just don’t highlight some issues, e.g. related to touch. Another alternative is to run Maemo virtually.

Mozilla/Maemo Danish Weekend 2009

At this point, bugs are good. If you come across any, please report them and make them block bug 492546 [Develop an extension showing a xul page in BrowserCanvas]. Vivien Nicolas of Mozilla Europe is working on identifying all XUL related bugs in Fennec, triaging, and following up on fixes.

ShareThis

In a recent post at Ken Kovash’s Blog of Metrics regarding Firefox in Latvia passing 50% market share, Indonesia was ranked at 63% market share. With such a love for Firefox, it’s also great to see that Indonesia has finally had it’s first Mozilla event last month.

Romi Hardiyanto, Mozilla’s localizer for Bahasa Indonesia, led an afternoon of presentations on Add-ons for Mozilla at ITS Surabaya, a university in the second-largest city in Indonesia. Romi has a great write-up of the event, Mozilla Day at ITS, at the brand new Mozilla Indonesia blog.

A photo of the students

HΛniF: Hadits, Now in Firefox

Photos from the event are available at Romi’s Flickr, Aini-san’s Picasa and Kiki’s Facebook.

I would like to take a moment to thank Romi Hardiyanto, Mozilla’s tireless Bahasa Indonesia localizer for Firefox who, in addition to localizing Firefox for Indonesians, is also working to spread Firefox farther in Indonesia. Thank you Romi!

This event would also not have happened without the support and coordination of Nur’ Aini Rakhmawati of ITS Surabaya who hosted the event. Thank you Aini-san!

Thank you also goes to Mary Colvig who provided support from Marketing/Events.

Since there has been so much interest in Add-ons in Indonesia, we would like to explore the possibility of doing a similar or related Mozilla-focused event in Jakarta later this year, after the launch of Firefox 3.5. If you would like to have a Mozilla event in Jakarta, please feel free to comment and leave your email so we can contact you. We are looking for people in Jakarta who would volunteer to help us with some of the organizational work to create such an event.

Here is Romi Hardiyanto’s presentation on Add-ons (in Bahasa Indonesia, not English.)

Here is Kiki Ahmadi’s presentation on the PureZilla add-on.

Thank you Romi and Aini-san and everyone who made Mozilla’s first event in Indonesia a success!

ShareThis

REQUIREMENTS
(We are on a tight schedule and have logistics constraints, so apologise for the deadline and geographical restrictions)

• Write a short proposal stating what your add-on name and current install location, why you think it would be useful to mobile browser users, and how you plan on going about implementing it. Send it to brian@mozdev.org by Friday 15 May, at 12:00 CET.
• This challenge is only open to developers living in Europe.
• The challenge open to current Mozdev project owners, and other developers who host their projects elsewhere.

PRIZE

• 10 developers will be chosen, and Mozilla Europe will sponsor your travel and hotel expenses to attend the Mozilla Maemo Danish Weekend.
• Entries will be judged by Mozdev representatives.

USEFUL RESOURCES
http://wiki.maemo.org/MozillaMaemoDanishWeekend
http://www.mozilla.org/projects/fennec/1.0b1/releasenotes/
https://wiki.mozilla.org/Mobile/Fennec/Extensions
https://wiki.mozilla.org/Mobile/Fennec/Architecture
http://starkravingfinkle.org/blog/tags/mobile/
http://www.mozdev.org/projects/applications/Fennec.html
https://addons.mozilla.org/en-US/fennec/

ShareThis

Over at Social Actions we’ve created an open database of 60,000+ actions from 40+ sites- including GlobalGiving, Change.org, DonorsChoose.org, Kiva.org, Nabuur, TakingITGlobal, Idealist.org, and VolunteerMatch.

What the Change the Web Challenge is about is getting these actions out there – by helping people find and share actions on the websites, blogs and social networks that we all visit everyday.

What makes Mozilla and Firefox add-ons in particular such a powerful platform for social change is that you can change the way people browse the web. You can add an intimate and direct layer of social change to the browsing experience. You can, with so many different possibilities, help people make a difference on any website.

For example, Marnie Webb created an Ubiquity command that lets you highlight any phrase on any site and find related ways to take action from Social Actions’ 40+ action sources.

Our community members have also imagined (read: not built) an extension that replaces ads with actions (a la AddArt), to another extension that would alert you to relevant actions as you browse the web (possibly like Collactive), to a browser-based feed reader with the latest actions categorized by cause (by re-skinning ObamaFox).

We hope you’ll join us in envisioning and building new Firefox extensions that combine the aggregated actions of Social Actions with the powerful reach and impact of Mozilla Firefox.

You can find out more about the Change the Web Challenge, including how to submit your project here.

More links:

• Change the Web Challenge Slideshow
• Social Actions’ Developers Google Group
• Developer Resources
• Firefox Extensions for Social Change (Slideshow)
• March 3rd, Online Chat, How Can Mozilla Empower Movements & Nonprofits

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

Creating software in a vacuum is incredibly difficult. While all add-on developers have a general idea of the value they’d like to deliver to their users, without copious and constant feedback it’s like flying in the dark. Knowing what your users want and what they don’t find interesting is incredibly important. It also helps to know what, if anything, they’re seeking and how they perceive what it is that your add-on does and how it works. Even if you’re delivering a valuable add-on, compatibility can also be a major issue since end users’ machines all look different and testing the limitless combinations of add-ons, desktop software and personal configurations is virtually impossible.

Listening and reacting to the people in the trenches can therefore make the difference between success and failure.

While it may seem daunting, you can take heart in the fact that users, when nurtured properly, can be an incredible resource for feedback, helpful advice, technical assistance and, on many occasions, even quality assurance. They can certainly be abrasive sometimes, but with a thick skin you can get tremendous value out of their “tough love.” In the spirit of trying to share a few thoughts, here are some humbly submitted, common sense ideas, along with a few tricks, that might help make the difference.

1. Actively Seek Feedback

The AMO page for every add-on enables users to leave comments. Check once a day for new feedback, post responses whenever appropriate and, when possible, follow up with the commenter if more information is needed. As a general rule, when communicating with users, keep it positive and constructive and control your emotions. While on occasion it might seem otherwise, malicious intent is extremely rare. Most people want to help, so always respond with that in mind.

The AMO page, however, should only be the beginning. For most add-ons, the percentage of people who download and then return to leave a comment is small. Finding other ways to elicit feedback is therefore imperative. Nevertheless, the challenge can be particularly difficult since it is not obviously when, where or how to ask for feedback. You could try to incorporate a feedback mechanism into the add-ons itself, but be careful about being overly intrusive. Real estate is very precious and most people don’t want things popping up at them. We have found, however, that one excellent way to resolve these issues is with an uninstall survey.

A survey page can be launched using an uninstall script. For actually running the survey and collecting the data, SurveyMonkey provides an excellent service. If you don’t mind having to erase the responses and start over every time you get 100 replies, you could run it for free. Keeping the survey very short will help conversion greatly. You might even consider one simple multiple-choice question: “Please tell us why you are uninstalling this add-on.” Allow for an open-ended response and consider making one of the answers “Temporary issue – I’ll be back!” While few people will leave an email, make sure to ask for it as those that do leave one will normally turn out to be very helpful.

Remember to keep your uninstall survey up to date. The open-ended responses will enable users to give whatever feedback they want, but if you use multiple-choice questions, make sure to keep the selections current with the functionality of your add-on. Moving the questions and responses around a bit will also help to remove “position bias” – people have a tendency to select the first choices.

We’ve found that the moment the user chooses to uninstall an add-on turns out to be an opportune time to request feedback. He or she has had an opportunity to evaluate the application and has just made a decision: to uninstall. Unfortunately this doesn’t afford a lot of opportunity for positive feedback (people who love the application will generally leave it installed and thus won’t ever see the survey, so you’ll have to find another mechanism for getting the positive reviews), but hearing from people who uninstall is what you really need to improve your add-on.

2. Meticulously Pursue All Leads

The majority of feedback, whether through the AMO page, the add-on’s website or the uninstall script, will not include contact information for the user. For obvious reasons, people are very reluctant to share their emails. In many cases, this can make the job of debugging or improving your application very difficult, especially when the feedback isn’t anything more than “it didn’t work.” Therefore, whenever a user is gracious enough to provide contact information along with the feedback, it’s important to capitalize on that opportunity to learn everything that you can. People who submit their email addresses are doing so for follow up, so don’t be afraid to contact them. That being said, restrict the communication to the subject matter at hand (their feedback) and don’t send them sales pitches or add them to any mailing lists.

Take pains to profusely express gratitude for their feedback at every opportunity. Pointing out how valuable their contributions are to resolving issues and improving your application, and then thanking them for their effort, turns out to be very helpful. It’s also the right thing to do. As a consequence, we’ve found that some people can be incredibly generous with their time and assistance. In order to debug issues, we’ve had people create new profiles for testing, uninstall and deactivate add-ons one at a time to find compatibility problems and install testing software as well as beta versions of our add-on. We even had one user send a video in order to demonstrate a particular thing he was experiencing.

Many people love problem solving and will look at providing you with useful information as a personal challenge. By offering them avenues for giving feedback, demonstrating respect for their time and offering them encouragement, AMO users will be an amazingly valuable resource for improving your add-on.

3. Relentlessly Make Improvements

Now that you’ve got the feedback and have an army of users helping you out, it’s naturally important to implement improvements as a result. New features and enhancements can take time to realize, but responding to your users should always be a top priority. That being said, just because one user asks for something doesn’t mean that you need to drop everything to deliver it, but with enough feedback you’ll begin to identify patterns. Keep in mind that if five people give similar feedback there might be hundreds out there that are thinking the same thing.

Compatibility issues can also be tricky to resolve since they typically involve other people’s software, although once again, other developers can be very helpful. If you reach out to developers with whom you have issues you’ll most likely find that most are eager to provide assistance. Add-on incompatibility issues work both ways, so it’s in everyone’s interest to work together. If another add-on developer were to contact you, I’m sure you’d do the same. Even if other developers are unable to modify their application in a timely fashion, perhaps they could help suggest a temporary work-around. We’ve found that the odds of not getting some form of assistance is very small and that most developers are enthusiastic about collaborating.

Finally, don’t hesitate to reach out to the AMO community for technical assistance. Many issues relating to the development of add-ons are tricky and a lot of the “art” is still being fashioned. Post questions to forums or send emails to other add-on developers. If you have a little bit of money to dedicate to something particular, RentACoder can be a cost-effective means of finding vetted developers with very specific talents.

I’m sure there are many other techniques for working with AMO users, but these suggestions might be a helpful place to get started. If other people have ideas, we’d love to hear them, so please post below. Everyone is always looking for ways to improve!

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

As the addon review queue grows beyond 600 nominated and updated addons, it is more important than ever to make sure your extension passes review the first time around. Editors have a review guide, and a well hidden but publicly viewable set of policies. But here is a quick list of the most cited reasons for addon refusal :

1. Addon should have at least 3 user reviews before being nominated. External reviews count too, but you have to mention them in your nomination message. Softpedia reviews do not count.
2. Wrap your loose variables. All objects, variables, and anything that your addon makes global should be wrapped to avoid conflicts with other addons.
3. Look at the error console. Is your extension throwing up javascript errors? Fix it. There are some options you can set in about:config to help you with this.
4. You break functionality in the host application (Firefox, Thunderbird, etc.).
5. Your extension doesn’t work properly, or showing unexpected results. This is what user reviews are expected to catch, but you really should get someone who wasn’t involved to test and report bugs.

There are other less common things that can get you busted too. I’ll just list them here for completeness sake :

1. Including remote javascript/css or other files, anywhere. Include them in your xpi file instead.
2. CSS warnings on the error console if your submitting a theme.

If you have any doubts, check the public policies page linked above.

And don’t ask when your extension will be reviewed in the comments. Because every answer will be the same : When someone gets around to it. It could be sooner if you’d help!

ShareThis