No for each loop

One of the nice things about writing a Firefox or Chrome extension is that both browsers are fairly standards compliant, and both support modern versions of javascript ( Version 1.8.1 as of Firefox 3.5. Chrome supports ECMA Script Edition 3, + roughly Javascript 1.7 ). This means stuff like properties, fun array methods and other little goodies. One of the things that Firefox supports is the for each loop, which is actually part of the E4X standard. This is a handy little item, it lets you loop through all of the items in an object, rather than the properties in an object. The catch? It’s not supported in chrome. I had to remove all of these loops in the my project’s code in order for chrome to even load my JavasScript.

No Preferences System

Firefox has a fairly nice preference system. Accessing it is a bit clunky, but the nice thing is that you can place an observer on any preference branch and get updates as soon as it changes.

In chrome there’s no such thing. There is localStorage, which you can use to store preferences, but if you want the observer functionality, you have to build it yourself.

I wrote a wrapper around localStorage to present a similar interface to Firefox for preferences, and added methods for registering observers. Because all of the pref changes that need observing are made by only by my project, I didn’t have to worry about observers getting updates if they changed through some other means.

No Password Storage

Firefox has nsILoginManager for storing passwords. By default these are stored unencrypted, but you can set a master password to encrypt them. In chrome, the only option for storing password is localStorage, which is unencrypted.

Different way to get the current window information

my project needs to know the URL of the current window so it can bookmark it. The way to access this information is different in each browser.

Firefox:

var info={url:getWebNavigation().currentURI.spec,
  title: getWebNavigation().document.title}

        chrome.tabs.getSelected(null, function _getWinInfo(tab){
                var info = {
                        url:tab.url,
                        title:tab.title
                };
            });

Different logging

My project has a bunch of built in logging. Much is for diagnostic purposes, but some is for important errors. For the most important errors Components.utils.reportError is used. This reports the error to the built in Firefox Error Console. It’s possible to report other errors to this console, but it’s more complicated.

The rest of logging in my project is provided by a home-grown logging service. Extensions in Firefox can write to disk, so that’s what the project’s logging service does. Chrome doesn’t allow extensions to write to disk. It does have a console object however, that can be used for logging at various levels (a la firebug).

To prevent having to change a bunch of code, I created a bridge to reportError:

//Fake out the report error method so we can still use it in code

    Components = {
            utils:console
    }
    Components.utils.reportError=console.error;

Different system for localization

Chrome’s localization system sucks.  The FF version isn’t great either, but I really hate the chrome one.  In FF you have two different ways to localize strings – in XUL, you can use DTDs.  This is a very strange use of DTD, but in practice it’s pretty straightforward.  In your XUL, you reference some string with an entity reference like &confirmButtonLabel;.  In your DTD you will have an entry like so:

somebundle.getString("somekey")

chrome.i18n.getMessage("somekey")

No Prompt Service

Firefox has the nsIPromptService which makes simple dialogs easy.  You can crate things from a simple alert (with control of the title) to a more complex dialog with multiple custom labeled buttons.  I haven’t ported the functionality needed to do this just yet, but when I do, I will probably use jQuery UI.

No Built In Widgets

getElementsByTagName is not scoped to the default namespace

Fortunately the solution isn’t that difficult, you just have to call getElementsByTagNameNS, passing in the default atom namespace. It’s an annoying thing to have to change, however.

Less tolerance for twice defined variables

if(someCondition){
    var something="xyz";
}else{
    var something="123";
}
alert(something);

if(someCondition){
    var something="xyz";
}else{
    something="123";
}
alert(something);

alert(something);but this makes the Java/C++ developer in me cringe. Instead, I did a more proper looking:

var something;
if(someCondition){
    something="xyz";
}else{
    something="123";
}

alert(something);