Porting a Firefox add-on to a Chrome extension

Google recently opened their Chrome extensions gallery for submissions. So I thought I would have a go at creating one. I’ve made three Firefox add-ons so I thought I would convert one of those.
I chose Wolfram Alpha Google as it has the least browser-related code of the three. Nearly all of it is regular Javascript.

Documentation and Set-up of development environment

The first major difference I noticed was in the quality of the documentation. While Chrome’s documentation is not as comprehensive as Firefox’s, it is much more logical and easier to understand for a first time user. The second difference was in the setup of a developer environment. The setup for Chrome is very straightforward, you put a description (manifest) file in one directory and select that directory from within the browser. Then you add JavaScript and CSS files and click reload in the browser to update each time. Compare this with Firefox where you need to use another add-on or mess around in the install directory to setup, change some hidden options, then restart the browser every time you make changes to browser code.

Extension Structure

Firefox requires that you structure your add-on in a particular way. You need to have CSS files in one place, language files in another and there is another file that links them all together. Firefox also has one file that describes the add-on. Chrome’s approach is more flexible. You can arrange the files however you want and all the configuration is done in one setup file, the manifest file.
The Manifest File
Both Chrome and Firefox have a manifest file that describes the extension. In Firefox, how the add-on integrates with the browser is defined in other files. With Chrome you include these details in the manifest file and the whole process is much simpler.

Scope of extension system

With Firefox you can modify basically any part of the browser that you want to. This is great in that it allows for more complex add-ons like Firebug, FireFTP etc. to be built. On the other hand though, most extensions make use of only a small subset of this power.
Chrome’s system limits extensions to a certain number of predefined use cases. Three of the main ones are “Browser Actions” (adds a button to the top toolbar), “Page Actions” (similar to Greasemonkey), and “Themes” (same as Firefox’s themes).

Problems with porting

I ran into quite a few problems while porting.

  1. Removing Firefox specific code– even fairly simple Firefox add-ons can have quite a bit of code specifc to Firefox for handling things like options etc. I needed to remove all of this code. Better structuring of the original add-on would have made this a lot simpler. Chrome makes use of HTML5’s local storage for storing options. Hopefully this will be easy to do in Firefox in the future too.
  2. innerHTML and innerText.
    Trying to set innerHTML was causing an unexplained error. A google search turned up lots of Chromium comits along the lines of “Removing use of innerHTML from example extension”. Another blog recommended using innerText which solved the problem. Not sure what’s going on here.
  3. Cross-site security restrictions
    Chrome’s system allows you to set exceptions for cross-site scripting but the security restrictions still apply to cross-site scripting between frames (the addon uses an iframe). The way to communicate between frames in Chrome is using a new feature of HTML5 called postMessage. I needed to reference the Firefox document for this one and it seems to work fairly well. My only problem was that the iframe has to first receive a message from the main page before it can communicate back but this can be worked around.
  4. Animated PNG’s don’t animate
    Tried to use an animated PNG file as a background image for a button. Unfortunately, Chrome only supports animated GIFs. Small issue but annoying nonetheless.
  5. Sandboxed Scripts
    The cross-site security restrictions also apply to the web page itself. This caused a serious problem as the Wolfram Alpha page attempted to access “parent” (the main page) and caused a JavaScript error. This error then caused the page to not finish loading. As Chrome sandboxes extensions from the website code, it’s not possible to modify the script to fix this. I haven’t solved this problem yet.

Other interesting differences

Chrome extensions are updated automatically in the background and you can restrict updates to certain versions. Firefox does the same but the update process is much more visible. The self-hosted updating system also looks a lot simpler than Firefox’s.


  • Google has created a very nice extension system that is straight-forward to develop for. While not being as powerful as Firefox’s system it should cover a majority of the add-ons out there.
  • The system seems a lot more secure than Firefox’s. By restricting what extensions can do it should limit the effect of many extensions causing the browser to slow down, which is an oft-cited problem with Firefox.
  • Having a simpler environment should make it easier to attract more developers as well. Nearly anything you can do in Chrome can also be done in Firefox so I don’t think we’ll see a huge amount of innovation in the browser experience but we will see a lot more site-specific, Greasemonkey-like extensions.
  • Mozilla’s Jetpack seems to be trying to create an extension environment similar to Chrome’s. Mozilla will likely include this in the browser once it stabilizes some more.
  • One nice thing to look out for is that Chrome extensions can easily support scripts for multiple sites in the one add-on. This should lead to some good “packs” of Greasemonkey-like scripts that change the browser experience across related sites.

As the extension is not working correctly (see Number 5 in Problems with Porting) I haven’t uploaded it to the Extensions Gallery. You can download it from Google Code (the source code is there as well) for the time being.
If anybody could help fix this problem it would be greatly appreciated.


  1. lil-Dexx says:

    I’m developing an add-on that I plan to port to chrome if it gets successfull enough. I already try not to use firefox specific code, but there are some stuff missing from chrome that bugs me a lot. Like hashing. In ff it’s a matter of a service, but in chrome you need your own javascript code to do that.

    Anyway, very good article, with good point, nice structure and easy to follow.

  2. Martin Smith says:

    Very nice article. I have developed a few Firefox extensions and I think that the documentation could be much better structured. Will look into chrome after reading this.

  3. Lakshman says:

    I have a firefox toolbar, wants to convert to chrome. This article is a good start point for me, will give it a try in the weekend.

  4. A41202813GMAIL says:

    Can Anyone Convert The FF FEBE Extension To CHROME, Please, Pretty Please ?

    That Is The Only FF Extension I Really Miss In CHROME.

    Thank You.

  5. Jahanzaib says:

    I am porting a Firefox addon to Chrome. The firefox addon is developed using the Addon SDK, and I figured it out that I will have to convert it to WebExtension. The Addon SDK addon uses Components object to interact with XPCOM objects which is not available in WebExtensions. Do you have any idea what alternative could be used?

  6. Avijeh says:

    Thanks. Do you know any extension like Rank Checker for Google Chrome?
    Because my job is SEO and I need this extension or something like that. Thank you.

Leave a Reply