Google has their own “Getting Started” tutorial which is extremely helpful. You can get your feet wet here:

http://code.google.com/chrome/extensions/getstarted.html

Note that at this point, you will need the Developer version of Chrome. You can grab it here:

http://www.chromium.org/getting-involved/dev-channel

Structure

The Chrome extension’s backbone is the manifest file. Specifically, manifest.js. It describes what will be packaged in the extension and describes the name, a brief description, whatever explicit permissions you grant it, and other details. The fields in full are described here:

http://code.google.com/chrome/extensions/manifest.html

The most basic Chrome extension only requires a manifest.js file and another javascript file. For this tutorial, we will use a pre-existing Firefox extension, which is a very basic one- Allow Right Click. This is simply a file that prevents attempts to inhibit the context menu from activating. This is seen on some web sites as a protection scheme of sorts, to try and prevent a user from saving an image or viewing the source. You can get around either of those by simply viewing the cache, but it does come in handy sometimes.

You can test out the effectiveness of the scripts here:

http://www.dynamicdrive.com/dynamicindex9/noright.htm
http://www.dynamicdrive.com/dynamicindex9/noright2.htm
http://www.dynamicdrive.com/dynamicindex9/noright3.htm

Function

Here is the bypass script in its entirety:

void(document.ondragstart=null);
void(document.oncontextmenu=null);
void(document.onselectstart=null);
void(document.onclick=null);
void(document.onmousedown=null);
void(document.onmouseup=null);
void(document.onbeforecopy=null);
void(document.onbeforecut=null);
void(document.oncopy=null)

Save this in a file by itself as rightclick.js.
This issues a series of null statements that will “void out” attempts to manipulate your context menu. The manifest file for this particular extension is below, which you can save as manifest.js, editing it as desired:


{
"authors": [ {
"email": "ehamiter@gmail.com",
"name": "Eric Hamiter"
} ],
"content_scripts": [ {
"js": [ "rightclick.js" ],
"matches": [ "http://*/*" ]
} ],
"description": "Bypass right-click prohibited pages.",
"homepage": "http://erichamiter.com",
"update_url": "http://erichamiter.com/chrome/updates.xml",
"name": "Allow Right Click",
"version": "1.0"
}


The first part is self-evident. The matches section will match any web page- in this case that is precisely what we want. In some cases, though, if you only want it to activate on certain pages, you can limit it here.

As of now, you cannot use a wildcard domain for the matches section- say, images.google.*. This would be very handy instead of matching images.google.com, images.google.co.uk, et cetera. You can get around this limitation by using a javascript trick in your script:


if (location.hostname.indexOf("images.google.") == 0) {

}


You’ll also notice an update section. This works the same as a Firefox extension- it checks an xml file on your server to see if there is a newer version. The updates.xml relevant section on my server is below:


<gupdate protocol="2.0">
<app appid="fhbfcblhfgbemciedggloeeekecmlhcf">
<updatecheck codebase="http://erichamiter.com/chrome/allowrightclick.crx" version="1.0"/>
</app>
</gupdate>


The app appid is generated by Chrome after you package the extension, which I will describe in a bit.

So, we have rightclick.js and manifest.js. Put both of these files in a single folder, named appropriately- “allowrightclick” or something similar. Simple is the best option.

In your Chrome browser, type in this address:

chrome://extensions/

Or alternatively, click on the wrench icon and select Extensions. You should see a screen similar to this one:

Toggle the developer mode selection, and you should see these choices: Load unpacked extension, Pack extension, Update extensions now.

For now, we want the first option: Load unpacked extension. Select it and it will prompt you for the location of your files. Select your folder and hit ok. I wound up with this (your ID will be random and unique, just like you):

Now try out the previous test sites and see if it’s working:

http://www.dynamicdrive.com/dynamicindex9/noright.htm
http://www.dynamicdrive.com/dynamicindex9/noright2.htm
http://www.dynamicdrive.com/dynamicindex9/noright3.htm

If you can successfully right-click and get a menu, it’s working! So, to pack up the extension as a bona-fide Chrome extension, you just visit your extension page again, and select “Pack extension.” Select the previous folder, and it will prompt you for the extension root and directory and an optional private key:

Select your directory again, and you do not need the private key file. If you edit or update the extension, then you can add the private key file which will generate in a moment, and then future updates will retain the same ID.

Chrome will pop up an alert box reminding you that you should keep your key safe:

It saves the two files (extension.crx and extension.pem) in the parent folder of your working extension directory. The .crx file is your new Chrome extension, ready to distribute and to be added to any Beta or Developer version of Chrome. The .pem file is your personal key file and you should keep it safe somewhere. This will be needed to update the file to maintain the same ID.

To test out the new file, uninstall your unpacked extension, and open your .crx file with Chrome. Control-O will open a file; navigate to your .crx file; hit continue, then install. You should get a notice that it has installed successfully.

There are a few different places for trying out new extensions:

https://chrome.google.com/extensions
http://www.chromeextensions.org/
http://www.chromeplugins.org

There are a small but steadily growing number of cool Chrome extensions out there. Create one today and let the world know about it.

Update! It is now a working extension, mostly thanks to Nick, developer of InfoLister, and master of jedi XUL tricks. I’ll leave the original article as below for informational purposes.

How useful is the current error page for Firefox? I’ll answer for you: not very. You have the option of trying again, which will do nothing for you 99 times out of 100. It’s a glorified reload button, except smaller and located lower. Do you ever even hit the thing? I don’t- it’s basically as useless as the screen from Internet Explorer telling you to ask your system administrator what just happened. So, I decided to spruce it up a bit.

Most of the time, if I run across a page that should be there but isn’t, I’d like to run a few tests on it- a trace route, a whois search or maybe ping the place. Another thing I’d like to do is see if there’s an entry in the wayback machine. The last but usually most useful is looking at google’s cache of the page. I’ve implemented all of these on this hack, as well as a superfluous use of Eric Meyer’s CSS Complexspiral technique.

To pull this off on your own, you need a vague understanding of Firefox’s structure, a text editor, and an archival program, used to compress things into zip files. Oh yeah, you’ll need these files (right-click, save as):

• mozilla1.gif
• mozilla2.gif
• netError.xhtml

I’m going to make a couple of assumptions, because it makes it easier on me, which is the imprtant thing. I’m assuming you’re going to use windows of some sort. Mac users can do this too, but I’m not sure exactly where all the files are you’ll need to wade through to do this. It may involve opening up some packages or something else that should be less confusing than it is. I’m also going to assume you know what Firefox is, since you’re going to be delving around under the hood of it.

Before you start, you will have to close Firefox. We’re going to be working on files that it uses in real-time. Read this article in its entirety before doing anything, then copy this post and paste it into your text editor.

Next, make backups of all of your files you might cry yourself to sleep over if you lost them. Cookies, bookmarks, extensions, etcetera. How you do this will not be discussed at the moment. Google usually knows all about things like that. Next, navigate to your Firefox directory in your Program Files folder.

Under your Mozilla Firefox folder, you should see a folder called chrome. Take note of the file toolkit.jar. This is what we’re going to be concerned with. Make a backup of this file in case something goes awry. Put it in a safe, warm place, like your desktop, or in some archival folder. Now, rename the original toolkit.jar to toolkit.zip. Windows will ask if you really want to do that- say yes. Now unzip that file in the current directory. This should create a folder named toolkit.

Navigate through your directory as such:

\toolkit\content\global

Rename the file netError.xhtml to netError.bak. Save those three files from eariler (the two .gif files and the .xhtml file) into this directory. Take a look through the .xhtml file with a text editor and you can see how the page is laid out, and modify anything you like. This isn’t necessary, but it can give you an idea of what is actually going on behind the scenes.

Once those files are saved, navigate back up the directory tree to the toolkit level. This is the only tricky step in the process. You want to re-zip everything back up: only from content on. You don’t want the actual toolkit folder in this archive. I have it so I can right-click on a folder in windows explorer and invoke my archival program, but yours may vary.

Important note: If you use WinRar, you must select “zip” as the archival type. A “rar” compression will corrupt the package and it will not work.

After the zipped file is created, rename it to toolkit.jar. Windows again will ask if you really want to do that- say yes. Now move it into the Mozilla Firefox/chrome folder, overwriting your original file.

That’s it- you’re done. Now you can have some marginally useful error pages, along with the benefit of looking underneath the hood of the Firefox engine. Don’t be afraid to poke around in there, you never know when you’ll come across something interesting.

Take note that if you update your browser, this file will disappear again, so make backups just as you would with anything else. I hope this has been handy for a couple of you out there. Feel free to comment on any other “hard” hacks that prove useful.

If you have the router in question:

…and the version number of it is 1-4, then you can upgrade the firmware in it to a 3rd-party one, which will allow you to configure a bunch of things that you were previously not able to. This is a cool thing, because you can fine-tune your setup, and add in other features like static DHCP leases. That means, for example, that you can always assign the same IP address to one of your laptops so you can keep your port forwarding options on it the same, but if you take your laptop down the road to Joe’s Wi_Fi spot, it will automatically grab it without you having to re-configure anything. It’s handy.

So, once you do it, because of the new options and wonderful toys, your once-stable connection might be dropping in and out a bit more than you would like. Some of the default settings on DD-WRT were not getting along with my modem at all. So much, in fact, that it made me question the modem’s general health, so I replaced it with a newer one. Same problems! So after scouring the internet for other people suffering from my connection’s problems, here’s a cluster of things I changed which resulted in a very solid configuration, and I have had zero dropped connections since, where they used to be one per every few hours.

µTorrent has a tip to help:

Special note for users with Linksys WRT54G/GL/GS routers, there are severe problems with them when running any P2P app (read for fix)


The default firmware for Linksys (and all replacement firmwares except for one) have a severe problem where they track old connections for FIVE days, which causes the router to hang when using P2P apps, or any software that generates a lot of connections. DHT only aggravates the situation because of the number of connections it generates.


Linksys has yet to address this issue, but there is a fix. If you use alternative firmware, you can put in a start-up script to fix this problem. DD-WRT and HyperWRT support custom start-up scripts. I am not responsible if you screw up your router, so you do this at your own risk. This page has instructions on recovering a bricked router.

I’ll walk you through how to do it with DD-WRT- the page has instructions for both DD-WRT and HyperWRT if you run that one instead. Note that these are my settings and are working great for me, which means that it probably will be for you too, but I can’t guarantee it. I advise you to do some more research about doing this if I’ve said at least one thing that you’re not toally sure about.


Go to Admin > Services and choose to enable SSHD. Save settings.
Download putty.exe if you don’t have it, and run it.

For host name, put in your router’s IP address. The default is 192.168.1.1. Leave the port at 22, and make sure the protocol is SSH. Hit open.
Login as root.
root@192.168.x.x’s password is your router’s password. If you’ve never changed it from the default setting, it’s admin.

At the ~ # prompt, enter the following (copy and paste one line at a time by copying a line below, then pasting it into putty by right clicking on putty’s screen, and hitting enter after each line):

nvram set rc_startup="
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo '600 1800 120 60 120 120 10 60 30 120' > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
"

Then you’ll be back to the ~ # prompt. Type in

nvram commit
reboot

Then the system will tell you The system is going down NOW !! Sending SIGTERM to all processes.That’s fine. Once it reboots, you can close putty and go to your web management console.

Go to your Management tab, and scroll down to IP Filter Settings. Change the Maximum Ports value to 4096 and the TCP and UDP to 300 each. Save settings.
Go to the Setup tab, and under Basic Setup, note the STP setting. If you have Comcast cable, disable this.
Under optional settings, the MTU size is set to auto. Change it to manual and enter 1392.
Go to the Wireless tab, and then select the subheader Adavnced Settings. Change the Xmit Power to 200 80.

Again, these are my settings and they work well for me. I will not take responsibility if you accidentally destroy your router trying to update it. Those that feel comfortable doing some thing like this, I urge you to try it out, it’s a noticeable increase in performance.

If you don’t have perl installed on your Windows machine, it’s a free download here: ActivePerl

It’s an easy setup, just click a few buttons, then you’re done. Then copy and paste the following into a new file and call it maxversion-updater.pl or anything, really, as long as you have the `pl` extension.

The easiest way to find where your profile folder is this:

Start > Run > %appdata%\Mozilla\Firefox\Profiles

Copy the 8 digits before the `.folder` and paste them in the script below.

- – -

#!/usr/bin/perl

use File::Find;
use strict;

# Firefox extension update script, written by Eric Hamiter
#
# This script will attempt to update extensions used on
# earlier builds of Firefox by changing the maxVersion fields.
# It will probably work, but might accidentally set
# your house on fire. I don’t accept responsibility for what
# might happen, so use at your own risk.
#
# Modify the following lines to point the variable to your
# Firefox profile directory and specify the new Firefox version.

my $default_folder=”xxxxxxxx.default”;
my $new_version=”1.5″;

# The rest of the script requires no modification.

my $max=”em:maxVersion”;
my $def=”$ENV{‘APPDATA’}\\Mozilla\\Firefox\\Profiles\\$default_folder”;
my $directory=”$def\\extensions”;

find (\&change, $directory);

sub change
{
my @newMax;
my $oldMax;

if ( $File::Find::name =~ /\.rdf$/ ) {

open (FILE, $File::Find::name ) or
die “Cannot open file: $!”;

print “\n” . $File::Find::name . “\n”;
while ( $oldMax = ) {
$oldMax =~ s/<$max>.*$new_version $oldMax =~ s/$max=".*"/$max="$new_version"/i;
push(@newMax, $oldMax);
}
close FILE;

open ( OUTFILE, ">$File::Find::name” ) or
die “Cannot open file: $!”;

print ( OUTFILE @newMax );
close ( OUTFILE );

undef( @newMax );
}
}

- – -

I tried the simple method of connecting directly to the share from Finder’s Network connection, but for whatever reason, it refused me access. I could see my computer, but there was no way of connecting to the printer. I quickly ran to Google for an alternative method.

Google told me that I could make this work, under the re-assuring article entitled, "How to Use a Printer Attached to a Windows XP Computer in Mac OS X” which just about hit the nail on the head. Unfortunately, the exact method described did not work for me, although it got me very close to success.

After reading another article, entitled "Five Cool Things to do with CUPS", I finally got it working.

This article is a mix and mash of the two mentioned articles, plus a few comments from myself that will hopefully be the fastest and clearest way to set up wireless printing on an OS X laptop. All of the original correct methods have been pioneered by the original authors, I’ve just taken the information and joined the bits that worked the best for me.

First things first: I am going to assume that your printer is already successfully hooked up and working on your Windows box. You should also have a wireless network set up and functioning correctly. I also am taking the assumption that you are at least vaguely familiar with the Windows XP and OS X environments, so if I mention the Control Panel on the XP box, you know how to get there, and so forth. If you don’t know, then ask our friend Google, he’ll help you out with a quickness.

Ok, now that all of that is out of the way, here’s what we need to do.

Get the Windows IP address. Fastest way to do this is go to Start > Run > and type in

cmd

Then in the new window, type

ipconfig

and write down the windows IP address; we’ll need it later. It should be in the ballpark of http://192.168.1.xxx or somewhere around there.

We need to tell Windows that we’re going to share the printer.
Click Start and then Control Panel. Then double click on Printers and Faxes. Right-click on your printer, then select Properties. Select the Sharing tab, set Sharing to on, and name the Share something short and sweet. Don’t use spaces, you don’t want to make this more complicated than you have to. My printer’s name is “printy”, which I think is accurate.

Ever since Service Pack 2 came out for Windows, additional security measures have been set in place, so we’ll need to manually open up an additional port, although we just told Windows to share the printer.

So go to Start > Control Panel > My Network Places > Network Connections.
New task on the left: Change Windows Firewall Settings, then click on the Exceptions tab. Click on Add Port, enter "OS X printer" (or whatever you want) in Name and "515" in Port Number. Leave TCP selected, click OK, OK and you’re done.

You might have to enable the Print Server service in the Services section of the Administrative Tools control panel. To check this, open Control Panel, then open Administrative Tools, then Services. Click on the Extended tab. Find the service TCP/IP Print Server, start it, and set it to start automatically.

Now we must set up print services for Unix. Click Start and then Control Panel. Double click on Add or Remove Programs. Click on Add/Remove Windows Components. Double click Other Network File and Print Services. Select Print Services for Unix. You might need your Windows XP CD, but I didn’t. Click OK to go back to the Add/Remove panel. Close it.

We’re done with the Windows box, now we need to get the Mac working with it.

Open a terminal window and type in:

cd /usr/libexec/cups/backend/

and then type in

sudo ln -s /usr/bin/smbspool smb

This creates a symbolic link for working with CUPS (Common Unix Printing System), if you’re curious about what you just typed in. After the sudo command, it will ask you for a password, so you need to have administrator’s privileges.

Now start up printer sharing from the Sharing Preference Pane. If you have already started it, you need to turn it off and then on again for CUPS to pick up the changes.

Go to the CUPS web interface at http://127.0.0.1:631

Select “Add Printer.”
Give it a name, a location, and a description. These can be whatever you want.

Then choose:

LPD/LPR Host or Printer

The URI is in this format:

lpd://your.windows.ipaddress.from-earlier/your-printers-shared-name

Then choose the make and model. If they don’t have it exactly, it will probably still work.

That’s it. Hopefully you can now print with ease from your toilet or your bed or wherever you want to now.

So you’ve learned how to write your own extension. This tutorial will show you how to keep your users up to date with your latest version automatically.

One of the cool things about having an update feature in your extension is the user won’t have to check your homepage all the time to see if there’s a new version available. Firefox will let them know that a new version is available as soon as you update it, thanks to a file called update.rdf.

update.rdf resides on your server’s directory; in my case, it’s here:

http://extensions.roachfiend.com/update.rdf

You can take a look at it if you want. You’ll see that it’s got syntax highlighting and colors on it. This is good. That means that my server is correctly identifying it as an rdf file, and not just some random text file. This is the number one reason why things go awry when you try and set up an update file. There are two ways of remedying this if you run into problems: the first and easiest method is if you have cpanel running on your server. If so, just go to MIME types, and then add a new type as the following:

MIME type: text/xml
Extension: rdf

If you don’t have cpanel installed, but you have an Apache server, you can add this to your root directory’s .htaccess file:

AddType text/xml rdf

Ok, now your server should recognize the file we’re going to create. Here’s a sample update.rdf file you can copy and paste, and edit as necessary. In this example we’ll track just one extension, but in my file posted above, you can see that you can keep tabs on a boatload of extensions.

Note: There is no space between Description about=”urn:mozilla:extension: and {b4fb60db…} on lines 5 and 6 below. I had to split them up because it was too long on the web page. Sorry if this is what caused your insanity. Thanks, Karl!

<?xml version="1.0"?>
<r:RDF xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
       xmlns="http://www.mozilla.org/2004/em-rdf#">
<!-- Foo Widget Extension -->
<r:Description about="urn:mozilla:extension:
{b4fb60db-ac1c-4c10-b0f6-39b0b0f56ea5}">
  <updates>
    <r:Seq>
      <r:li>
        <r:Description>
          <version>0.1</version>
          <targetApplication>
            <r:Description>
              <id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</id>
              <minVersion>0.8</minVersion>
              <maxVersion>1.9</maxVersion>
              <updateLink>http://www.webserver.com/foowidget.xpi</updateLink>
            </r:Description>
          </targetApplication>
        </r:Description>
      </r:li>
    </r:Seq>
  </updates>
  <version>0.1</version>
  <updateLink>http://www.webserver.com/foowidget.xpi</updateLink>
</r:Description>
</r:RDF>

So you would need to replace the web address and extension path as your own, as well as the first GUID that starts with b4fb… with your extension’s GUID. The second one that begins with ec80… is unique to Firefox, so leave that alone.

You’ll notice two <version> tags- in the past sometimes the mechanism ignored any attributes outside of the <updates> tags, so having two ensured compatibility. To be honest, I don’t know if both are necessary, but it works, so hey, whatever. Put the current version number of your extension in there, so Firefox will have a new version to check against. If the number in here is greater than the user’s current release, then it will prompt them to install the new version.

So, we’ve got the modified update.rdf file on the server. Now we need to tell the extension to call home to see if there’s a newer version. In your install.rdf file, you need this line:

<em:updateURL>http://www.webserver.com/update.rdf</em:updateURL>

That’s it! You can test it out by keeping an old version of an extension installed on your browser (that has the updateURL above in place) and uploading the new version on your server.

(If you’d like to see how to create a Google Chrome extension, you can read this article here: http://roachfiend.com/archives/2009/12/27/how-to-write-google-chrome-extensions/)

Everyone has a good idea at one time or another to implement a new feature in a web browser. Well, with the goodness that is Mozilla Firefox, now you can do just that. You need to have a vague understanding of XUL and Javascript, but you certainly don’t need to be a master of either. When I started, I knew nothing about either one, really. I had seen some bookmarklets here and there, and tried to figure out just how they worked. Well, that’s how I made my first extension, BugMeNot.

Contents

1. Learn By Example
2. Hello, world!
3. Looking inside the XPI
4. Re-configuring your extension’s installation
5. Chrome is more than a shiny bumper
6. Skin that cat
7. Pack it up and try it out
8. An easier way to re-build
9. My Firefox got completely hosed up
10. Ensure server compatibility
11. Additonal help and information
12. Comments / Feedback

Learn by example

Everyone has a good idea at one time or another to implement a new feature in a web browser. Well, with the goodness that is Mozilla Firefox, now you can do just that. You need to have a vague understanding of XUL and Javascript, but you certainly don’t need to be a master of either. When I started, I knew nothing about either one, really. I had seen some bookmarklets here and there, and tried to figure out just how they worked. Well, that’s how I made my first extension, BugMeNot.

Basically, this tutorial will show you how to create your first extension from scratch. Since
every programmer always learns from the famous “Hello, world!” example, I figured that would be a good way to introduce you to developing extensions.

Xul Planet has a nice little tutorial which will show you the basics of creating a menu. Mozilla also has a very handy DOM Window Interface reference if you’d like to take a look through that. They’re both geared toward an audience that has a good feel for programming, though, so it’s not necessary to understand everything going on to follow this tutorial.

Hello, world!

Our extension will be a nice simple one that will pop up a window proclaiming “Hello, world!” after we select it either in a right-click menu, or under the Tools menu. Both of these places are very popular positions, and it’s relatively easy to stick something in there.

Let’s see what the end result looks like, so you know what to expect. First, here are the two ways to access our extension:

Right-clicking will get us this:

The tools menu looks like this:

The end result of our extension’s efforts:

What it looks like in the extension manager:

Clicking on the “About…” in the extension manager will get us this:

Looking inside the XPI

Here’s how the extension breaks down in a nutshell, using a pre-made Hello, world! extension as an example:

(You can download it here, just right-click and save, then you can follow along.)

helloworld.xpi is the packaged extension. XPI is just an file format that your browser will recognize as a browser extension. In reality, it’s just a zipped up file. So you can rename the XPI to ZIP or even JAR if you want, then open it up using an archive program, like 7-Zip or WinRAR. So, once that’s opened up, you’ll see:

• chrome
• install.js
• install.rdf

A folder and two files. install.js was all you used to need for the installation, but now that the extension manager has changed (since Firefox 0.9), the install.rdf is used instead. Now, the install.js is used purely for earlier versions of Firefox/bird, Mozilla, and Netscape. If you want to make this extension solely for 0.9+ versions of Firefox, then you can omit this file if you’d like. I tend to
keep it in because it only take a second to make, and assures a wide audience compatibility. Some extensions simply aren’t backwards-compatible, though, for example my ListZilla
extension, since it gathers all information from 0.9′s extensions manager. A nice simple “Hello, world!” prompt shouldn’t present any problems, though.

If you open up install.js, you’ll see that it’s very basic, in terms of what you need to modify to make your own install script:

// --- Editable items begin ---
extFullName: 'Hello, world!', // The name displayed to the user
extShortName: 'helloworld', // The leafname of the JAR file
extVersion: '0.1',
extAuthor: 'Eric Hamiter',
extLocaleNames: null, // e.g. ['en-US', 'en-GB']
extSkinNames: null, // e.g. ['classic', 'modern']
extPostInstallMessage: 'Success! Please restart your browser to finish the
installation.'
// Set to null for no post-install message
// --- Editable items end ---

So all the hard work is done for you. I’m not going post the rest of the code, but you’ll see
quite a lengthy amount of work that is fully automated.

Now if you open install.rdf. you’ll see 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>{9AA46F4F-4DC7-4c06-97AF-5035170633FE}</em:id>
		<em:name>Hello, world!</em:name>
		<em:version>0.1</em:version>
		<em:description>Displays an alert message via right-click
		or Tools menu.</em:description>
		<em:creator>Eric Hamiter</em:creator>
		<em:homepageURL>http://extensions.roachfiend.com</em:homepageURL>
		<em:iconURL>chrome://helloworld/skin/helloworld.png</em:iconURL>
		<em:aboutURL>chrome://helloworld/content/about.xul</em:aboutURL>
		<em:file>
			<Description about="urn:mozilla:extension:file:helloworld.jar">
				<em:package>content/helloworld/</em:package>
				<em:skin>skin/classic/helloworld/</em:skin>
			</Description>
		</em:file>

		<em:targetApplication>
			<Description>
				<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
				<em:minVersion>0.7</em:minVersion>
				<em:maxVersion>9.9</em:maxVersion>
			</Description>
		</em:targetApplication>

	</Description>

</RDF>

Re-configuring your extension’s installation

Ok, whoa.. what is all this crap? The first thing you’ll see is the <em:id> tag. This is your very own generated id that will separate your extension from anyone else’s. There are a few ways to make it. You can either use
an online perl script to randomly generate one, or if you use Windows, you can use a program called guidgen,
brought to us by Microsoft. How deliciously ironic. Or am I misuing the term irony here? Whatever. So if you download that, then you’ll see this when you run it:

So choose 4. Registry Format, then hit New GUID a few times for good measure, then Copy. That’s it, now your new spiffy id is in your clipboard. Replace the old one with this, and you’re set.

Name, version, description, creator, and homepageURL are all self-explanatory. The iconURL and aboutURL are what shows up if someone right-clicks your extension and chooses “About Extension…”. You can leave these blank, it’s not mandatory, but it’s nice to have a little flash every now and then.

Underneath file, this is standard stuff. Just replace all instances of “helloworld” with your extension name. This is where the installation will try and find your files and folders. If you have any icons, you’ll include the skin folder. Again, it’s not mandatory.

Target application is what you’re gearing this for. The ec8030f7… is unique to Firefox, so leave that alone. The minversion and maxversion is what versions of Firefox it will be compatible with. There was a big stink about this recently, since the developers introduced 0.9.1, shortly after telling us to make sure and only put a maxVersion of 0.9. This does not compute. So I recently modified mine to go to 9.9, which will ensure compatibility through the next few versions of Firefox. This isn’t the type of thing that mozilla will support, since they can only recommend keeping the maxVersion to the current release, but it’s the best way to keep you sane, so you don’t have to update your extensions every few weeeks.

Chrome is more than a shiny bumper

Ok, now open up the chrome folder. In there you’ll find another archived file, helloworld.jar. Open it up and extract the files. You’ll now have content and skin folders. Let’s explore content first. In there, we have a
helloworld folder, and under that, these files:

• about.xul
• contents.rdf
• helloworldOverlay.js
• helloworldOverlay.xul

about.xul is the file you see when you click “About Hello, world!…” in the extensions menu. It’s pretty self-explanatory, and you’ll see that a nice man named Jed Brown wrote the template for it, so all the hard work has been done for you. Again. So just fill out the info, and that’s it.

helloworldOverlay.xul and helloworldOverlay.js are what make things happen. They’re the brains behind the outfit, so to speak. And you’ll be amazed at how simple they are. Here’s helloworldOverlay.xul:

<?xml version="1.0"?>

<overlay id="helloworldOverlay"
         xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<!-- This imports our javascript. -->

<script type="application/x-javascript"
src="chrome://helloworld/content/helloworldOverlay.js">

</script>

<!-- This is for the right click menu. -->

<popup id="contentAreaContextMenu">
  <menuitem id="helloworld" label="Hello, world!" accesskey="H"
  insertafter="context-stop" oncommand="hello();"/>
</popup>

<!-- This is for the Tools menu. -->

<menupopup id="menu_ToolsPopup">
	<menuitem insertafter="devToolsSeparator" label="Hello, world!"
	accesskey="H" oncommand="hello();" />
</menupopup>

</overlay>

So all it says to do is to insert the javascript file, helloworldOverlay.js, and to create a context menu entry called Hello, world! accesskey=”H”
underlines the “H”, since it’s the first letter that wasn’t taken by any other options. insertafter=”context-stop” places the option directly underneath the Stop label. oncommand makes it launch the window with the
function hello, which is located in the javascript file we imported earlier. The second part of the overlay tells it we also want to place an option in the Tools menu. Same logic as the context menu, just a different place to stick it. Here’s what helloworldOverlay.js looks like:

// This is our javascript, which will pop up our message
// in an alert box.

function hello(){
	alert("Hello, world!");
}

Now for contents.rdf. This is the file that tells the browser where to store this overlay information. Here’s what it looks like:

<?xml version="1.0"?>

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

	<RDF:Seq RDF:about="urn:mozilla:package:root">
		<RDF:li RDF:resource="urn:mozilla:package:helloworld"/>
	</RDF:Seq>

	<RDF:Seq RDF:about="urn:mozilla:overlays">
		<RDF:li RDF:resource="chrome://browser/content/browser.xul"/>
		<RDF:li RDF:resource="chrome://navigator/content/navigator.xul"/>
	</RDF:Seq>

	<RDF:Seq RDF:about="chrome://browser/content/browser.xul">
		<RDF:li>chrome://helloworld/content/helloworldOverlay.xul</RDF:li>
	</RDF:Seq>

	<RDF:Seq about="chrome://navigator/content/navigator.xul">
		<RDF:li>chrome://helloworld/content/helloworldOverlay.xul</RDF:li>
	</RDF:Seq>

	<RDF:Description RDF:about="urn:mozilla:package:helloworld"
		chrome:displayName="Hello, world! 0.1"
		chrome:author="Eric Hamiter"
		chrome:authorURL="mailto:ehamiter@gmail.com"
		chrome:name="helloworld"
		chrome:extension="true"
		chrome:description="Displays an alert message via right-click
		or Tools menu.">
	</RDF:Description>

</RDF:RDF>

You’ll notice the address chrome://browser/content/browser.xul up there. This is mozilla’s internal frame of reference.
browser is the actual browser, and navigator works for non-Firefox builds, like Netscape or Mozilla. The only part you’d need to modify is the descriptions. The rest of it just implements the extension into the browsers.

Skin that cat

Now let’s backtrack to the skin folder. In it, we’ll find a few more folders: classic and helloworld. This is just the traditional layout, and if it ain’t broke, then hey, don’t fix it. In helloworld, we find three files: helloworld.png, helloworldb.png, and a contents.rdf file.

helloworld.png:

helloworldb.png:

These are called from about.xul mentioned previously,
for use in the extension menu and the about menu. contents.rdf simply maps out the paths to the skin files, so the only modification you need to change for your own extension is in the last line, which points to the folder helloworld.

Pack it up and try it out

So now that you see how the files work, and where they’re packaged, you can modify them to your whims, and try out new things. Once you modify them, just pack them up in reverse order. Using your archive program, you would navigate back up to the chrome folder, and add content and
skin into a zipped archive, then rename it to extension.jar. After that, navigate up another folder, and add chrome, install.rdf, and install.js into another zipped archive, then rename it to extension.xpi.

You’re ready to test it out in your browser now. Open up Firefox, and hit CTRL-O, or Open File. Load up your xpi file, and say yes to the installation. Restart Firefox, and hopefully you’ll see your new extension in the menu, and it does whatever you had hoped it would do.

An easier way to re-build

After a while, it gets tiresome to select your files, your folder, archive them, rename them, move them, delete them, rename them… you get my point. If you have 7-Zip installed, you can use the command line feature, so you can have this all fully automated. Here’s what you need to do:

Copy C:\Program Files\7-Zip\7z.exe to C:\WINDOWS\system32 (This will
put 7z.exe in your system’s path, which will make it accessible from the command prompt).

It’s a good practice to build your extensions somewhere far away from random scripts and clutter, so create a new folder somewhere and call it whatever your extension is named. Make sure it matches the internal .jar file that you previously referenced in your install.rdf file. You can always rename the final xpi to something more intricate afterward, but for packaging, it’s best to keep it simple.

Copy the following script and paste it in a text editor and save it as build.bat in your newly-made folder:

set x=%cd%
md build\chrome
cd chrome
7z a -tzip "%x%.jar" * -r -mx=0
move "%x%.jar" ..\build\chrome
cd ..
copy install.* build
cd build
7z a -tzip "%x%.xpi" * -r -mx=9
move "%x%.xpi" ..\
cd ..
rd build /s/q

Now, you can build or modify your extensions easily. Just use the new folder as your
base of creation, so that would contain the install files and chrome folder. Whenever you want to create your new file, just double-click build.bat, and your new extension will pop out in the same folder. Each time you use the build.bat script, it will
delete your old file and create a new one.

My Firefox just got completely hosed up

Worst case scenario: upon restarting Firefox, it hangs with a “Firefox is still installing an
extension, this may take a minute…”. This means you borked it up somehow. Don’t panic! A super easy way of uninstalling it without hosing the rest of your shit up is as follows:

Start » Program Files » Mozilla Firefox » Mozilla Firefox (Safe Mode)

Then go to Tools » Extensions » [right-click on your extension] » Uninstall

Restart Firefox, and it’ll be gone. Then modify your files and try again.

Ensure server compatibility

If it works, and you want to put it on your web server, but find out that it won’t install directly, and your browser is treating it as “Save File As..” then you need to modify your .htaccess file. You can learn more about it here, but
for brevity’s sake, you need your server to run on Apache for it to work. If you have no problem modifying the file, here’s the information you need to add:

Add this to your .htaccess file:

AddType application/x-xpinstall xpi

And you should be set.

Additional help and information

If you want to take a look at any other files I’ve created, they’re on my main
extensions page, and I’ll list them directly here for convenience as well:

• Allow Right-Click
• Alt-Text for Links
• Always Remember Password
• BugMeNot
• Ext2Abc
• Google Images Re-Linker
• Goon Menu
• ListZilla
• Teleflip
• Word Count

If you’d like to put a certain snippet of Javascript on every page,
Allow Right-Click or Always Remember Password is the way to go. Alt-Text for Links uses javascript to control tooltips. If you’d like to create your own links menu, then Goon Menu is good to learn from. BugMeNot uses complex regular expressions, ListZilla deals with
setting options and using the extension manager, and WordCount is a good way to learn how to take a bookmarklet and use it as an extension.

The Mozillazine extensions forum is a great place to learn more about creating extensions. They’re under heavy loads from time to time, so they might be down when you read this, but try back again if they are, because they have a lot of useful information there.

Loads of other useful extensions can also be found at Mozilla Update, and there’s another place called My Extensions Mirror that has forums as well as tons of extensions.

Well, that’s it. Hopefully this has been helpful to at least a few ambitious people, as well as a look into what goes into making one for the non-technical types. So get off your ass and make something useful!