Lessons Learned: Firefox Extension Development

I have been developing a Firefox extension for work in order to make some web development tasks really quick and easy. It’s one of those many-hour projects that saves several minutes here and there. It will have been worth it by the time I graduate… in theory. Though I have only been working on the project for a couple of days, I thought I would post some of the important Lessons Learned so far. I hope I don’t need a part two later on down the road…

Create a separate profile for development
Everyone likes to think, “I won’t make that mistake!” It’s a great thought and a lot like world peace: it’s not going to happen. At some point, your extension itself might cause trouble with Firefox. Maybe you’re a perfect programmer though (ha!) and so you make no mistakes. You’re still likely to add some other extensions to make development easier and those could cause profile anguish. It’s a lot easier to nuke an extension development profile than the one that has all your ad-blocking extensions, grandma’s recipe links, and transformers-are-still-cool-to-me theme.

JavaScript is MORE of a pain in extensions
I am not sure if I know anyone who actually likes JavaScript or is even an “expert” with it. JS can do some really cool things, but testing can be a pain, behavior can seem inconsistent, and cross-browser support is more than a little frustrating. I think the people who wrote Prototype, script.aculo.us, and moo.fx are among the few who can consider themselves “accomplished” in the field of JavaScript. The rest of us throw something together (often based on those frameworks) and break a mouse, keyboard, and/or monitor while throwing forth a passel of swearwords. Eventually, it either works or it is “good enough.”

With extensions, you have to look at JavaScript from another perspective. The code is running from a “chrome” url (example: copy this into your FF address bar chrome://browser/content/browser.xul) rather than HTTP, meaning that you have to look at DOM manipulation from outside of the webpage you wish to alter or to affect in some way. You also have to make some changes in order to have FF even tell you that there are JavaScript errors and you have to constantly reload the browser (or use one of the extensions that reloads XUL/Chrome/etc.) to see your changes. In this case, PITA doesn’t refer to Middle Eastern bread…

Firefox has a safe mode!
I don’t know if this is because Windows made it the “cool” (and extremely necessary) thing to do or if the people responsible for Firefox realized that others would be creating add-ons and other content that could really destroy the browser. I managed to make FF take 700+ MB of RAM within a few minutes (and not because of my extension) and to make the Tools menu non-functional. Fortunately, you can start Firefox with the “-safe-mode” flag.

Firefox safe mode does NOT solve all problems
Unfortunately, I quickly found out that safe mode doesn’t solve all problems. It’s a good way to deal with skin and/or extension issues, but not necessarily to solve profile problems.

Google doesn’t solve all problems
This one really amazed me. I kept searching for “omg wtf I killed my firefox tools menu,” but I wasn’t having any luck. Normally, you can find a plethora of information about anything with search engines, even searching for a string like, “error 1234.” I am finding out that only works when a lot of people are having the problem. Not too many people are making Firefox extensions. Not too many don’t give up early enough to save their browser from eventual issues. Of those who are left, most of them could probably write their own browsers, given the time. Me, I just resort to “colorful vocabulary.”

user.js preferences are copied to prefs.js
Several of the tutorials I read talked about putting preferences in your user.js file. I figured, “That file is read each time FF opens, so you could set some prefs there, play around, remove them, restart Firefox, and all would be back to default,” and I was extremely wrong. If you change a preference in user.js, it is then changed in prefs.js and that preference stays even if you clear or delete your user.js file. I am not really sure why anyone suggests putting preferences in your user.js file, nor am I sure why they don’t mention “P.S. This might seem harmless, but you could really screw up Firefox.” When I eventually learned the mysteries of the user file, I was able to remove it and to manually edit the preferences file, finally beginning to recover from the “Why is FF suddenly behaving like IE?” thoughts.


0 Responses to “Lessons Learned: Firefox Extension Development”

  1. No Comments

Leave a Reply