Found this as an installed add-on in my Firefox browser. It didn’t seem related to Firefox sync/weave, so after some tracking it turns out to be a Nokia extension. It is one binary component.

I don’t like the name Nokia chose. It gives no indication that it comes from them, and it gives the impression that it comes directly from Firefox.

Last week, I was tasked at work to create a quick prototype extension. This machine had a few other extensions, including the very verbose SmartSwipe extension. SmartSwipe extension logs almost everything to the error console as messages. Which in turns makes it a pretty bad choice for any other extension who wants to use the error console as a logging service (incidentally, I am the main developer of the SmartSwipe extension, so this is entirely my fault).

Despite Firefox extensions growing more complex, there are two areas of extension development that are still a pain to deal with: debugging and logging.

What pains me is that extensions have a pretty crappy choice of methods to use for logging purposes. There is dump(), Components.utils.reportError(), FUEL’s Application.console.log(), and maybe some others I am missing (ChromeBug is another possibility, but I haven’t used it). But these methods of logging don’t scale very well. If you have more than 1 extension using the same logging service, you introduce noise that can be difficult to sort through.

It striked me that there was nothing simple to capture and filter your logging information. Since this problem was annoying me, I decided to create an extension to deal with this.

Introducing Debug Log

The extension is uncreatively called Debug Log (unrelated to Jeremy Gillick’s DebugLogger). It shows a Windows-style event viewer with basic filtering. To use it is really easy. First I will show how it is used, and next how to use it when the Debug Log extension isn’t installed:

var log = {};
(function() {
        var modules = {};
        Components.utils.import("chrome://debuglog/content/DebugLog.jsm",
        modules);
        log = new modules.DebugLog("my_extension_slug_name");
        log.info("Hello")
        log.warn("Trimming to 8 characters. String : " + s);
        log.error("MyTerribleFunction", exception);
        log.assert(foo != null, "foo should never be null");
})();

Which results in the following:

Assert is a bit different from typical assertion in other languages. It will not quit the application, nor would it throw an exception (unless you passed a wrong parameter to assert).

To use it properly, you must also account for times when DebugLog is not installed.

var logging = {};
(function() {
        try
        {
                var modules = {};
                Components.utils.import("chrome://debuglog/content/DebugLog.jsm",
                modules);
                logging = new modules.DebugLog("JavascriptPlusPlus");
        }
        catch (e)
        {
                logging.assert = logging.warn = logging.info = logging.error = function() {}
        }
})()
logging.info("Starting...");

The extension still has a lot of work to be done, but it’s useable now. So now is the time to release and it is available at https://addons.mozilla.org/en-US/firefox/addon/246799/. Enjoy!

I am in the process of creating a new Firefox add-on that will hopefully change a bit how we navigate some sites. Until now, keyboard navigation for the vast majority of sites has been simply unusable. Even though websites have a layout that can easily use a keyboard, it often relies on either remembering shortcuts or tabbing through. You are almost exclusively limited to a mouse when using a full-featured browser such as Firefox, Chrome, and IE.

Personally, I hate using the trackpad on my laptop. After extended use, the heat and the friction take a toll on my fingers. I have an external USB mouse, but that often becomes a bother as the laptop is moved around from one location to another. Yes, wireless mice, but again we’re not really fixing the problem.

For simple navigation, it’s almost a crime that I cannot tab between links and major components of a web site’s navigation.

The tabindex HTML attribute has gone largely unused when browsing the web. Perhaps for a myriad of reasons – it’s hard to re-order manually, and for many web developers it’s not worth the time or effort.

Even for everyday use, it becomes ridiculous how crappy it the tab key can be. Think about this:

• For a Google search result, the tab key must be hit 12 times before it focuses on your search text. Another 3 tab strikes before it takes you to the first result. Another 5 times or more to get to the second result – not counting Google’s quick links.
• For planet.mozilla.org, each tab key will go through every anchor link in each person’s blog post. Oh, and it takes 6 tab keystrokes to go to the first article.
• For reddit, it can be a little better. If you just use tab, you’ll go through each “share” link first. Which is stupid. If you activate “jump to content” it will go through image->link->domain->usersubreddit->comments. Which is still a lot for one result.

This is how I would order the tab key on a Google search result:

Possible tab order on google

I would probably use the top Google bar the least when doing a google search. Each time you hit tab, it will cycle through the search box, 1st result, 2nd result, etc. until you hit n-th result.

This would be great in an ideal world. A Firefox extension could do this, but for my purposes my extension does not do this. It doesn’t map the tab key. It instead uses the key right above it. Like tab, CTRL+` will cycle forward and SHIFT+~ will cycle backwards.

I call it tabcomplete. It’s not as pretty as tabcandy. I think a large part of my user-base wouldn’t be most users. Users seem content on using the mouse, and that’s fine. But for a guy who works in vim, this is a nice to have extension.

This was originally written early September. The patch was live late September. And 4 weeks of results later, this post. My apologies if I mixed past and present tense

The number of add-on downloads was always an interesting figure to me. Over several months, one of my add-ons was getting over 100 downloads a week without any promotion. But my ADU remains almost constant every week. It may increase by a few, but compared to the number of downloads, it only seemed like I got an abnormally low number of conversions. Less than 15% of users who downloaded my add-on turned into a ADU.

This didn’t seem right, so for 0.7 release of Safe extension, I added some code that sent me some info whenever someone uninstalled from the Add-ons Manager.

According to the add-ons dashboard, I had 78 ADU users for version 0.7 (submitted 2009-08-14. Averaged over a period of 1 week.).

How many downloads since it was uploaded? About 659 (I likely uploaded it late evening, so it might be less then that). So about 11% of the users that downloaded the extension didn’t uninstall it. But how many users chose to uninstall it using the Add-ons manager?

Ten.

So what of the other 500+ users? How did they uninstall my extension? I wondered whether web crawlers were downloading my extension. 500 seems like an awfully big number. Maybe a broken crawler? Well, actually, it turned out that AMO’s robot.txt did not exclude robots from downloading extensions at all. And how often a crawler visits is determined by the provider. Google cache takes a snapshot around once every week for me.

I realized that these numbers won’t be accurate because there are more ways to uninstall an add-on, including new profile or deleting the add-ons folder from the profile. But these seem like rare cases. Certainly not responsible for such a misleading number.

I filed and fixed a earlier bug to have robots.txt exclude crawlers from the /downloads/ path of each of our localized versions of AMO.

After 4 weeks, my stats have leveled off and the number of downloads have dropped by about 10 a day. My add-on downloads dropped from >10 to about 3 a day. This won’t be considerable to popular add-ons (AdBlock Plus shows no difference, they are still getting 80,000 downloads a day). Looking at the statistics on AMO, total downloads have dropped over 100,000 a day since the stuff went live last month. Good stuff.

Today I submitted version 0.7 of the safe add-on. This was not a version with additional features, but rather a version that collects stats from users who uninstall the add-on.

I mainly did this because I wanted to know more about why only a small percentage of users who downloaded my extension continued on using it. How long have they used the extension? What options have they enabled (if any)? Where are my users coming from? I stopped short of asking people to complete a feedback form, instead opting to just send data to my server. It’s relatively anonymous, except for the IP address which gets recorded.

Unfortunately, this doesn’t really give me useful statistics from people who stay with my add-on. Which is still useful. My best hope is that it’ll answer at least one of my questions that it was set out to answer.

As the addon review queue grows beyond 600 nominated and updated addons, it is more important than ever to make sure your extension passes review the first time around. Editors have a review guide, and a well hidden but publicly viewable set of policies. But here is a quick list of the most cited reasons for addon refusal :

1. Addon should have at least 3 user reviews before being nominated. External reviews count too, but you have to mention them in your nomination message. Softpedia reviews do not count.
2. Wrap your loose variables. All objects, variables, and anything that your addon makes global should be wrapped to avoid conflicts with other addons.
3. Look at the error console. Is your extension throwing up javascript errors? Fix it. There are some options you can set in about:config to help you with this.
4. You break functionality in the host application (Firefox, Thunderbird, etc.).
5. Your extension doesn’t work properly, or showing unexpected results. This is what user reviews are expected to catch, but you really should get someone who wasn’t involved to test and report bugs.

There are other less common things that can get you busted too. I’ll just list them here for completeness sake :

5. Including remote javascript/css or other files, anywhere. Include them in your xpi file instead.
6. CSS warnings on the error console if your submitting a theme.

If you have any doubts, check the public policies page linked above.

And don’t ask when your extension will be reviewed in the comments. Because every answer will be the same : When someone gets around to it. It could be sooner if you’d help!

Synopsis :
python addonParser.py extension.xpi

Description :
A simple python script that lexically analysis Firefox extensions, trying to find any problems. Outputs any problems to the terminal.

Requires :
Python Image Library

Notes :
Writes any .jar files into the $PWD/temp/ directory.

Breakdown of output :
examing chrome/ (13)
examing chrome/content/ (13)
examing chrome/content/botOFF.png (13)
examing chrome/content/botON.png (13)
examing chrome/content/dowint.css (13)
examing chrome/content/dowint.js (13)
examing chrome/content/dowint.xul (13)
        WARNING: http://dowint.net/inc/js.php does not start with chrome:// and not a local file for file chrome/content/dowint.xul (5)
examing chrome/content/logo.gif (13)
        WARNING: Image chrome/content/logo.gif does not match it's extension. Expected GIF, got PNG (2)
examing chrome.manifest (13)
examing install.rdf (13)

Numbers in parentheses at the end of line are just for debugging use only.
Text in square parentheses is often the source of the problem (used when evaluating javascript files)

Types :
Warning – something is wrong or possibly needs some examining
Error – I don’t know how to evaluate this (eg. files that I wasn’t expecting, or files that I don’t know how to properly evaluate)

Quirks (some people call this bugs) :

1. Sometimes it gives you information, but not enough context:
   WARNING: found XMLHttpRequest [var req = new XMLHttpRequest();] in file content/hrtoolbar.js (9)
2. Sometimes the output is extremely long because the js file was minified:
   WARNING: found XMLHttpRequest [var CC=Components.classes;var CI=Components.interfaces;var ... ]
3. False positives can be quite common :
   WARNING: found reference to outside source [@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");] in file skin/webwean.css. (8)
   (This is common false positive in CSS files. Though it has found a problem once)

Undecided Issues :

• What to do about .dtd and .properties (should anything be done for these files?)
• Should XHR throw up a warning? It’s fairly common, and we’re really just worried about eval.

Checks and Errors :

File :
Currently available here. Will upload repository later.

Please be advised that this tool is extremely stupid, and not a substitute for careful reviews

I made a post several months ago about an diffing zippy files on the web. While that stuff landed, it was difficult to use because I deferred actually showing what files changed to a later date. oops

Well, that made it nearly useless, because it was less effort to download each xpi file and do a diff locally.

Well, I’m glad to say that I’ve right a worlds wrong. Some stuff I was working on finally landed recently (can’t remember when. But it wasn’t working two days ago. So somewhere between Monday and today). So you may notice a few changes.

The first being the side panel that shows all the files. Any files that were modified appear italicized. Which is a bit subtle, but is the only indication I could give that wouldn’t make it stick out like a bad rash, or a honda element. Suggestions welcome.

Side Panel

So this pretty much completes what was started. Only some minor improvements were made since the last post. Including a wikipedia colour style diff :

Full screen view

I hope that this will be useful to AMO editors and help speed up the reviews. Which is in much better shape than they were two months ago.

I’ve been spending a few days on trying to develop a few tools for editors to use to quickly reject addons for obvious defects, such as loading remote scripts. But I wanted to get deeper into the javascript stuff mainly because it’s a) it’s harder and b) it’s where the real problems lie.

But as anyone can tell you, it’s not an easy task (going towards damn near impossible). Firstly, you can’t really use a lexical parser. Well, you can, but it won’t be dependable. Let’s take an example out of the Reviewer’s guide :

document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));

Which is sneaky way of creating a script element, though I question the competence of someone who will use this as their main line of attack (it’s practically spelled out for you). But taking this as a use case, and ignoring the fact that they can use document[cheese] instead, I wondering if parsing the javascript would make figuring this stuff out any better.

Happily, I have spidermonkey and a js shell to do any parsing I wish. But I found out some cool things that you can do in the shell, such as looking at the bytecode for an entire function using the dis() command.

This was interesting. Certainly, there are some optimizations you can do for :
document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));
I would be shocked if it didn’t end up spelling out :
document["createElement"]("script");

I had a few hurdles to overcome. Firstly, document is not defined in the javascript shell. Thinking it was defined in the xpcshell (owww. I was misled by some apparently unused tests and my general ignorance that xpcshell tests went into unit/ and not js/ directory) I went through the added trouble of coping dis() and related functions from js.cpp to xpcshell.cpp. Once I realized that document wasn’t defined, I made a document mock object just to see what the blasted bytecode would look like.

I was a little disappointed. This source:

var document = {
createElement : function(s) {
print("damn");
}
};

function foo() {
document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));
}

dis(foo);

Ended up being this bytecode :

00000:  name "document"
00003:  string "createElement"
00006:  callelem
00007:  string "s"
00010:  string "c"
00013:  add
00014:  string "r"
00017:  add
00018:  newinit 3
00020:  zero
00021:  string "i"
00024:  initelem
00025:  one
00026:  string "p"
00029:  initelem
00030:  int8 2
00032:  string "t"
00035:  initelem
00036:  endinit
00037:  callprop "join"
00040:  string ""
00043:  call 1
00046:  add
00047:  call 1
00050:  pop
00051:  stop

Source notes:
  0:     0 [   0] newline
  1:     6 [   6] pcbase   offset 6
  3:    37 [  31] xdelta
  4:    37 [   0] pcbase   offset 19
  6:    43 [   6] pcbase   offset 25
  8:    47 [   4] pcbase   offset 47

So, almost. The document["createElement"] part was correct, but the .join() wasn’t optimized. Although I wasn’t overly estatic, I knew that this was just one (somewhat lame) use case in the countless of possible others.

This is making me rethink whether lexical tools are the way to go. While they don’t give you any definitive proof that there is a possible security hole, they can still be useful. For example, if you want to use XMLHttpRequest, then you have to call it at least once in your program (even if you say var Widget = XMLHttpRequest). And at least that can bring up warning flags, or at least give editors a place to look.

I don’t think any tool can completely replace a human being. But hopefully, tools will help make the review process easier because you can start looking at high-risk areas first rather than starting from a arbitrary point and not coming across something until 10 minutes later.

I’ve been sorta hiding this behind a mac that is currently behind a locked building in an office somewhere in Mountain View, but thought that now was a good time as any to demonstrate what I have been working on.

The project is called My Lists. In a nutshell, it allows users to generate and publish a list of addons. For example, you may want to generate a list of the best web developers extensions you can find. So you include extensions such as the Extension Developer’s extension, and Firebug. You can then share this list with friends, or post a link to your website. Other users can then directly download these extensions from that page.

You can get a demonstration of what a list looks like at a remora instance I put up on this site. Of course, you need a username/password to generate your own list (and find the page that lets you do it ).

The hope is that this list will be used with other websites, through a web service. I currently have a service that does that by reading XML from a post request.

None of this is really done. Everything is very dis-jointed. You can’t tell what lists a user created or who created a list. Still needs polish. But just wanted to get the project out there in the open.