Update: Firefox has used the WebExtensions API as its extension API since 2017. We encourage you to visit Extension Workshop to learn more about browser extensions and how you can build an extension for Firefox. You can find reference documentation for the WebExtensions API on MDN.
Please do not reference this article for extension development, as it is out-of-date. If you are the developer of a legacy add-on, please refer to this page for resources to help you migrate to the current API.
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.
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:
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:
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.
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:
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).
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.
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.
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:
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.
There were a lot of discussions about developing your extensions a couple of years ago, and somewhere the know-how and tutorials have gone missing the last couple of years (or at least the good ones), this post is really, really good and will probably help a lot of people in the community start building extensions. Keep up the good work Robert.
Very good explanation in understanding of developing an add-on in firefox. This will be a very good startup for me. I faced a problem while installing the add-on as per the content of the files in your explanation. xmlns and xmlns:em values in install.rdf should have RDF in smaller case. This was correct in your download xpi file.
Undoubtedly, this is one of the best articles I came across while I was looking at my whys, hows, and whats for my plugin development. I have read the complete article and had hands-on as well. Having done that, I still could not get three questions answered.
hello everyone,
I am trying to develop an add-on to firefox for speech recognition which will enable the user to perform a search through an existing search engine.
so as mentioned in the article i will develop the extension using XUL and java script.
but what about the speech recognition part..for example lets take feature extraction..how do i implement those? should i implement those using another language and have a pointer to that in java script???
Have a Mac Mini running that had this problem under OSX 10.8 and is persisting in 10.9. When this computers reaches the self-provisioning portal, after clicking submit on the MAC address registration, the following screen displays an erroneous error that Java isn't installed.
Have gone through updating Java from Apple (2013-005) as well as from Oracle/Java (1.7), and applied several variations of uninstalling and reinstalling Java, doesn't seem to make a difference. From the top, the Mac Mini attaches to Wifi and the self-provisioning page appears with an authentication request. User authenticates succesfully. The next page displays the MAC address for the machine and a description field. Upon filling out the description, the page is submitted. The following page tha should complete the provisioning process, rather, displays an error that Java isn't installed and the user should go to java.com to complete the installation. According to the Java.com, Java is installed. According to terminal (by executing the command "java -version"), Java is installed. Running other Java applications, like JDE, run perfectly well. The self-provisioning page seems to be unaware of Java despite everything else. Ideas?
Which browser are you using if Safari, by default Safari disables Java if it isnt completely up to date. Also after the install has the browser been restarted? Try checking the link here under the Safari section to see if you can enable it manually and try running through the SPW process.
Thanks. No dice. The instructions on that page also appear to be woefully out of date too. In Safari, on the preferences security tab, there is no checkbox for "Enable Java" (I think that is a Safari 6.0.4 thing on OS X 10.8 or thereabouts). In OS X 10.9 there's just the "allow plugins" checkbox and the "manage website settings" button. Assuming this is where it's at now, moving to the Java plugin in the list, they were already "allow". I went a step further and set it for the three websites listed (that include the provisioning portal domain) to "allow always". No luck. Then went to another step further and click "run in unsafe mode" for every item in the Java website list and again it made no difference. The self provisioning portal page still says that Java isn't installed :-(
For Firefox, the instructions on that page are out of date too. Under what I believe are the correct settings, the Java applet plug-in for 7.45 is set to "always activate". I assume this is the same thing as seeing the "disable" button in previous FF versions, indicating that the job applet plug-in is actively running.
The chrome instructions on the page are irrelevant because my OS X and hardware are 64-bit and so is Java but not chrome. Therefore Java doesn't run on chrome on this machine in the first place.
I don't know who's browser the self provisioning portal fires up since it fires up its own window, not a Firefox or Safari specific one. In windows for example the self-provisioning portal fires up a tab in IE. That actually makes it simpler to debug IMO.
Any more advice? Java seems to be running just fine for every thing else. What am I missing?
UPDATE (Just another thought)
Alternatively, could it be a the with WebKit? Or Cisco's implementation of WebKit (as far as whether any changes would have been required for OS X 10.9 in the way with kids is instantiated)? If or example the self provisioning portal is opening up its own "browser" by using the Safari webkit function (as opposed to opening a tab directly in Safari itself) could this be a bug in Safari itself, or a changed API that Cisco has failed to implement (considering the other incompatibilities various Cisco products have with OS X 10.9)? I just hope that the problem is something that I can fix with a workaround rather than waiting for a patch from either Apple or Cisco that may or may not come anytime soon? :-/
If you are using Mac OS X clients with Java 7, you cannot download the Agents using Google Chrome browser. Java 7 runs only on 64-bit browsers and Chrome is a 32-bit browser. It is recommended to use either previous versions of Java or other browsers while downloading the Agents.
If you are using Mac OS X clients with Java 7, you cannot download the SPWs using Google Chrome browser. Java 7 runs only on 64-bit browsers and Chrome is a 32-bit browser. It is recommended to use either previous versions of Java or other browsers while downloading the SPWs.
Thanks, but I may have been unclear in my original post. My default browser is Safari 7.0 in OS X 10.9. I also have Firefox 24.0 installed, and I know that you can't use Chrome because of the 24 bit Java problem. I've gone ahead and uninstalled Chrome too so there's no Chrome any longer on my system. Just Safari 7.0 and Firefox 24.0 and Java 7.45.
Any idea why the self-provisioning portal says "Please install the latest Java..." after I click submit on the screen to register my hardware MAC address? AFAICT, the Cisco page does not see that Java is installed.
I observe that in OS X anyhow, the Cisco self-provisioning portal page is a box up dialog box, not a separate tab in an open browser, like in Windows IE. Therefore, it may also be helpful to know the mechanics of what Cisco's doing here, and why it's different than on Windows?
d3342ee215