Category: Mozilla

Recently I’ve seen a large number of add-ons get nominated for public on addons.mozilla.org (AMO) that didn’t meet some of the basic requirements that an author is supposed to meet. I thought it might be a good idea to let add-on developers know what it is that I look for when I take a look at the public nomination queue. Hopefully they’ll stop nominating things that don’t meet the requirements.

1. Does the add-on have any reviews from its users?

   AMO requires an add-on to have reviews from its users for it to even be considered for public nomination. Without reviews, we editors cannot effectively do our job. This is the most common reason that I have seen for an add-on being denied in the public nomination queue.

2. Are the reviews for the add-on simple, or are they more like a technical review?

   Reviews such as “This is a great extension!” or “This theme looks really nice” are not very helpful. These type of reviews do give me an idea on how useful people think your add-on might be, but that is not enough for public nomination. If an add-on only has a few reviews, and they are like those two examples, I’ll often be inclined to retain the add-on in the sandbox.

   The reviews that I really look for are people who install the add-on, test it, and report their findings. A report on a broken feature, with the platform (Windows, OS X, Linux), application (Firefox, Thunderbird) and its version, and the version of the extension is an awesome review. Reviews that go over what the reviewer tested and what they liked and didn’t like (with some details) are just as useful. If there are a few reports about a broken feature, I’ll be inclined to retain it in the sandbox and indicate that to the author. However, if there are enough favorable technical reviews, I’ll continue the process.

3. Is the author responsive?

   If there are discussion posts associated with the add-on, I like to check and see if the author is responding, or is essentially ignoring them. If it has been several weeks since a post was posted, and still no response from the author, I’ll be inclined to retain an add-on in the sandbox, as per the AMO policy. If there are no discussion posts, I’ll look to see if there is another place where the author distributes the add-on and see if there are posts there. Same guidelines apply. If the author seems responsive, or there are no posts to be found, I move on to the next step.

4. Is the add-on clearly and accurately described?

   I’m not going to deny you for a typo, but if your description is false or too vague, you’ll have to fix that and then re-nominate. If you add-on has had a few versions released, I’ll look at version notes and see how well you update them. I won’t deny it again for poor version notes, but I will make a note of it in the comment, and expect you to fix it. Editors will look at it next time you submit a version and ensure that you are doing as you are told by other editors.

5. Are all privacy and security concerns clearly spelled out?

   This one is really simple. If the add-on is sending user data over the internet, it will probably need some sort of privacy policy. If the add-on doesn’t do that, it’s best to leave the field blank because AMO will have a warning that you have a privacy policy right next to the install button, and this could scare users away. Same thing goes for the EULA.

6. Is the add-on free of unlicensed trademarks or copyrights?

   The policy page is pretty clear about this. AMO doesn’t want to host anything that violates anybody’s trademarks or copyrights, so please don’t nominate it.

7. Do the add-on and add-on author both treat the user respectfully?

   If you add-on starts installing unnecessary software, forces its toolbar to be always visible, or other things that are not respectful for the user, it will be kept in the sandbox. Your extension should be a good citizen in the application you target and provide the user with options to turn off features if they choose to do so (this is highly subjective and not always necessary).

8. Has the add-on been well-tested, and is it free of obvious or serious defects?

   This is probably the most time consuming part of the editing process for me. After I install the add-on and restart my browser (or Thunderbird if I’m testing an add-on for it), the first thing I check is for any errors or warnings in the Error Console. I have the Console² extension which allows you to enabled strict warnings and filter errors and warnings so you only see the ones from chrome code. I strongly recommend every add-on author to check their work with this before nominating it for public. Warnings are generally OK, but we expect the number of warnings to go down with each release (not up, nor staying constant). Errors all depend on what the error is, and if it breaks functionality. Those, however, I expect to be fixed in the next release of your extension.

   Now I’ll start to play with the functionality of the add-on, keeping the error console visible so I can see if normal use triggers any warnings or errors. If things are working as advertised, this add-on is one step closer to being approved. If not, I evaluate each issue on a case by case basis as to whether or not this issue is something that should keep the add-on in the sandbox.

   Finally, I’ll start to look at the source code of the add-on. What I am looking for here is basically glaring mistakes in the code, potential conflicts with other extensions, and privacy and security issues. Any one of these issues is enough to keep the add-on in the sandbox, but I always make sure to state how to go about fixing the code so the author can do so quickly and renominate.

If the add-on makes it all the way through that, it will be approved, and I get to move on to the next one.

One of my tasks this summer is to investigate the inclusion of Firebug in some distribution of Firefox. I’ve been playing with Firebug, submitting some patches to Joe, and trying to get a good feel for the codebase there. I have to say that it is a bit rough (and could really use some documentation), but I’m getting there. If I have time available, I’ll document things a bit better too.

The whole point of this is to present three questions to the community that I’d like to get input on. Leaving a comment is the best way to answer these questions:

1. What does the DOM Inspector do that Firebug doesn’t?
2. What does Venkman do that Firebug doesn’t?
3. How would Firebug being included in some distribution of Firefox affect web developers?

I’m looking for answers to these questions with the perspective of a web developer. That is to say that I’m not concerned (at least for now) that Firebug doesn’t inspect chrome, so features specific to that should try to be avoided.

I’ve got a build of Firebug with XPCNativeWrappers enabled (normally they are disabled). This build is also working in Firefox 3. The problem I have, however, is that I do not know how to use Firebug all that well. I’ve tested basic functionality, and it seems to work, but I really need some people to test the hell out of it.

I expect things to not work, especially the debugger. So, if you find something that doesn’t work, let me know and try to provide a url and steps to reproduce.

Install Firebug Test Build

UPDATE: So, I didn’t actually up the maxversion of the extension. Also, XPCNativeWrappers are a bad idea since it will only let you use DOM methods (kinda useless for a lot of sites). I’ll be working on this more today…

Now that the download manager back-end changes have landed and have stabilized, I figured that it’d be a good idea to get the word out. Basically, all of the RDF code has been pulled out, and we’ve switched over to using mozStorage as our back-end. The data is now stored in downloads.sqlite in your profile directory, and we do import the data from the existing file, downloads.rdf.

Doing this brought about changes to several interfaces (see Bug 380250). We no longer have the following methods and attributes for nsIDownloadManager because they were RDF related:

• void startBatchUpdate()
• void endBatchUpdate()
• readonly attribute nsIRDFDataSource datasource

To replace the datasource attribute, readonly attribute mozIStorageConnection DBConnection was added. This gives you access to the mozIStorageConnection that the download manager uses.

Several methods were modified from using a persistent descriptor to using a download id. The persistent descriptor was overly complex, so we decided to can it in favor of a simple unsigned 32-bit integer that is automatically assigned by the database.

• nsIDownload getDownload(in unsigned long aID)
• void cancelDownload(in unsigned long aID)
• void removeDownload(in unsigned long aID)
• void pauseDownload(in unsigned long aID)
• void resumeDownload(in unsigned long aID)
• void open(in nsIDOMWindow aParent, in unsigned long aID)

Lastly, activeDownloads no longer returns an nsISupportsArray. Now it returns an nsISimpleEnumerator.