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.

As an AMO editor, one thing you have to do is code review for security flaws. When doing update reviews, the best way to do this is to download the extension update that is currently in sandbox, and the last public release and unzip the zippy and jar files (unless your lucky and your diff program does this for you), than compare the results using a tool such as kDiff3, meld, or WinMerge.

I’m trying to change that by starting a project that will let you compare two files online. I’ve done some work and think it’s a good time to get my idea out to those who will use it.

Here is a screenshot of the output. You can test a sample output at this page :

One of the first thing you might notice is that this isn’t a side-by-side diff. The reason for that is that editors typically aren’t worried about what was taken out, but what was put in (while what was taken out might be more useful for extension developers). There is also the code that hasn’t changed, which is useful for referencing functions if it is ever needed.

It’s a simple php file. I hope to have some feedback whether people will use this tool or not (and saying “I use x because I know it best” is totally fine too. I’m trying to focus my energy on what will be used).

So I have been on vacation for less than a week and I’m already disappointed with myself.

Firstly, I haven’t been keeping up with my AMO responsibilities. I really need to do this, but I find myself being distracted every few hours.

Secondly, I haven’t gotten anywhere near as much work done with Prism as I wanted. I want to fix three bugs, two of which I already assigned to me :

1. Adding Preferences as an extension
2. Installing a webapp should automatically fill in the name with the title of the website if not already present
3. Lastly, I want the extension to search for .js files in the .webapp file and load a security warning, as webapp.js files have chrome level privileges

And there is more stuff obviously. This website. Shopping for summer clothes. Getting paperwork out of the way. Hanging out with friends.

Damn you Playstation and Wintendo!