The man behind the site.
Did you know you can mark bugzilla comments, making them appear to be highlighted? timeless recently pointed this out on irc, and I figured a lot of people didn’t know about this really neat feature. All you have to do is add &mark={comments} to the query string of the url, and can you can highlight away! The comments can be specified in a comma separated list, and/or you can specify ranges.
I’ve marked up my first fixed bug as an example.
I landed the upgrade to SQLite today to get us up to version 3.3.17. The version in trunk is horribly old, so we really need this upgrade. Sadly, Windows didn’t like it and the patch is now backed out again :(
Hopefully I’ll get a patch tomorrow that doesn’t hang on shutdown. Now, I’m off to go play in the land of multi-threaded code – hurray!
Two more download manager back-end changes landed recently. First, Bug 382825 added a potentially useful method:
void retryDownload(in unsigned long aID);
This will retry a download with the specified id, and fails if it cannot find the download in the database or if the download is currently in progress.
Then Bug 382839 landed, which enables getDownload to return both active downloads and any download that is in the database. Extension authors will not have to directly query the database to get the information they need about the download.
I think this is probably about it for back-end changes for Firefox 3. Still fixing a few random regressions that have popped up, and an interesting leak was found, but otherwise, it is about time to move onto the UI overhaul!
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.
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.
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.
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.
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.
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.
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.
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).
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:
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.