Oxymoronical

You might have heard of this web-browser. It’s called Firefox. You may have also heard that a new version is due out soon. As my part in its development I have helped completely reshape the way the add-ons manager looks. The good news is that the large bits of the changes are pretty much done, pretty much all that is left is a bunch of UI tweaks and some small behaviour changes.

This is where you come in. Yes you, the one reading this post. If you have an urge to help out you can look through this list of things we want to get done on the add-ons manager before release, pick one out and go nuts. These are all things that shouldn’t require very much experience working on the add-ons manager or even Firefox in general, though of course some are easier than others. We have some great information about how to get started and also a great community who can help out if you get stuck. So if you’ve ever had a hankering to get involved this would be a great time to dive in.

Once again that list is here: http://bit.ly/duYWdP, give me or Blair a shout if you have questions or don’t know where to get started.

Many of you nightly testers may have noticed that Nightly Tester Tools’ compatibility override feature doesn’t work with the new add-ons manager and may be wondering when I’m planning to issue an update to fix that. The more astute of you may have noticed that there hasn’t actually been a real code update to Nightly Tester Tools in 2 years, barring a couple of simple app compatibility fixes. Those with a sharp memory will remember that I said just under 2 years ago that I was ceasing work on my extensions in my spare time. I suggested that Nightly Tester Tools might still receive the odd update but obviously that hasn’t happened and the truth is that I can’t see it happening anytime soon. I’m too busy with that whole real life thing to even be able to work on projects I do enjoy, let alone maintain old stuff that no longer really interests me.

This unfortunately leaves a sizable number of users losing a feature that they liked and still potentially have a need for. I can only really see a couple of possible roads to follow from here:

1. Do nothing. Users will be annoyed for a time but eventually find ways around what they needed NTT for.
2. Find someone else to pick up and maintain NTT. I’ve had numerous requests for the source code for many of my extensions over the past two years, none have ever apparently tried to do anything though. Perhaps someone out there will pick up the torch this time?
3. Point all the users to something else, like the Add-on Compatibility Reporter (once that is updated to work on trunk). While nothing else I know of works quite like NTT at least something is better than nothing, and ACR has the benefit of being Mozilla supported, provides Mozilla with valuable information about add-on compatibility and may be rolled into Firefox at some point.

Option 3 is the only one available that involves any work on my part but probably the choice that leads to less user annoyance, unless someone reading this wants to take up the challenge or has a better idea?

I’ve never been terribly impressed with my current digital camera. It’s an Olympus FE-280 that I bought on the spur of the moment in Boston a few years ago when my previous camera decided it didn’t want to stay charged any longer. Feature-wise the Olympus probably has almost everything I want, but its menu system is so convoluted that I can never find how to enable the things I’m after in a reasonable amount of time. In the past few years it has slowly developed some bad pixels (both on the view screen itself and on the CCD cell and now the battery charger is starting to flash ominously suggesting that the battery is about to go to a better place so I think it is about time to start looking for a replacement and this time I want to do some research.

Sadly I know probably just enough about taking photos to make me dangerous which means that I occasionally want to do things that probably warrant use of some expensive feature-packed camera. While I would love the power of something like a digital SLR the reality is I I would barely make use of all its features and I need something smaller otherwise I will never carry it around with me. But here is a list of the features I am after, maybe someone has suggestions for cameras that have all of these and more?

• An easy to use mode that does fast exposures
• Good motion stabilization
• A way to take a quick sequence of images with one press of the shutter
• Maybe manual focusing to allow shooting through windows
• Orientation detection, ideally actually orienting the image file but I guess just putting the EXIF orientation marker is a start
• I’d sort of love to get RAW images to play around with in the occasion the camera hasn’t been clever enough to work out what I want

Update: So I guess everyone is recommending either one of the Lumix series or the Canon S90. The latter seems to provide more control over shooting at first glance but then the Panasonic site doesn’t offer the full instruction manual for the Lumix cameras, only basic instructions which makes figuring out exactly what you can do with them and how a little more tricky. The Lumix cameras do claim a faster fps in burst mode and all have more zoom than the S90′s relatively paltry 3.8x. I wonder how much use zoom is though when I’m not going to be using a tripod for shooting.

It’s been quite some time since I last worked on my prototype XPCOM component/interface viewer and I have to face facts, it’s likely to be quite some time till I do again. I haven’t even had time to update it with the data from the latest 1.9.2 and trunk interfaces. Since I’m not likely to go anywhere else with this I’d love for someone else who thinks it is worthwhile to pick it up and run with it. I’ve just done a final commit adding a README on how to use the code (though I’m sure it is lacking in key ways so be prepared to have to experiment a bit) and the full source is available in my hg repository. The code is MPL tri-licensed so you should just be able to fork and go do your own thing. I should be able to answer any questions and would love to see it get finished and really usable somewhere.

I’ve just rolled out a small update to the interface cross reference, nothing major, just fixing a few bugs and I’ve put up what looks like the final set of interfaces for 1.9.1b2.

I’ve now figured out the best way to gather the interface lists and so the cross reference now includes all interfaces used in all 3 major platforms of Firefox. It is relatively simple for me to add the interfaces for other applications now but this got me thinking about what kind of uses people are making of this and how the multi-OS, multi-app interfaces should be presented. A few ideas came to mind:

• App developers probably just want to see the interfaces in their app, either only those that appear for all operating systems or those for a specific OS in some cases.
• Add-on developers probably want to see some kind of shared set of interfaces (what you might call gecko/toolkit) that appear for all apps they are targeting, unfortunately this changes depending on the set of apps. Again they probably want for all OS or for a specific OS.
• Maybe I shouldn’t even bother doing anything and just include a note in the interface display about where the interface actually exists.

I’m sure other people have other ideas of how it might work, any suggestions?

I forgot to add to my last post some information about what I currently had in mind to improve about the API reference I’ve been working on. Any further suggestions people have are very welcome, but here is the current few ideas I have.

Currently it only indexes Firefox and Gecko interfaces, in fact it only indexes those used by an OSX build of Firefox. It would be nice to be able to index interfaces for all the main applications and for all the platforms. There are a couple of issues with this. Firstly I’d want the UI to work so people viewing it could select what set of interfaces they wanted to see. Secondly actually building the lists of interfaces for each application and OS is going to be pretty tricky I think. So far I’ve resorted to building Firefox then looking in dist/idl. This works but it is time consuming. Possibly I might be able to come up with some clever nonsense to make the build system only compile idls but we’ll see.

It would be nice to be able to include a list of the component contract ids available in the platform and what interfaces they implement. This is I think pretty difficult to do just by parsing the source files. Potentially a little extension could run in the app and do some looking through Components.classes to find this out. One issue here though is there is no way to tell whether components are services or not so instantiating them is potentially problematic. This is a problem that could be solved by brute force, or maybe doing a special instrumented build.

So those are my main two ideas, if anyone has any suggestions on how to make those tasks easier or for other things that should be there then shout them out.

Faaborg has started a discussion on the newsgroups on the relative importance of polish and blocker bugs (I’d provide a link bug Google Groups seems to be refusing to acknowledge existence of the post). I have been for quite some time now very focused on the in-depth blocker issues, partly because that is where all the interesting work is for me, but also because I think it makes more sense for me or one of the other guys with good understandings of how the extension manager works to be making these changes rather than throwing others in at the deep end.

This has of course left little time for me to fix the trivial issues that Faaborg talks about. The things that users probably notice more and make the product look complete or half-done. This is why I’m really pleased that when I posted a list of simple bugs that anyone should be able to tackle there was a fairly good response. Of the 12 bugs on the original list, 9 have been fixed. I wanted to extend my thanks to those guys that took the time to work on those, some of them probably ended up being a little harder work than anticipated.

Of course the polish list is almost never ending. I’ve been adding more to the list of good first bugs, if anyone is interested in helping out then don’t be afraid to just email me or find me on IRC as Mossop and ask how much work something really involves.

I was very excited to learn at the Firefox Summit that Rob Strong was handing over ownership of the Extension Manager module to me. He did great work making the extension manager what it is today but has lately had to be more focused on Installer and windows integration issues.

Last week I spent a large part of my time trying to get myself up to speed on all the old filed bugs, clearing out things that clearly aren’t going to happen and trying to consolidate others. In particular I made the effort to go over every single unconfirmed bug and either resolve as appropriate or request any additional information from the reporter. It is rather sad that many of these were issues that noone commented in after the initial report or even worse the reporter responded with additional information but people (including me) dropped the ball and nothing further happened.

This big triage has been quite useful. Firstly the number of unconfirmed bugs for the add-ons manager has dropped from the mid 70s to under 30 (I would give you exact figures and pretty graphs but bugzilla’s charting is broken). I expect it to drop even further next week when I resolve the issues where the reporter is no longer responding to bugmail. Secondly it has allowed me to spot a pattern amongst 6 or so filed bugs which strongly suggests a new issue that can break add-on installations. While I have yet to be able to reproduce it in a test environment I certainly have more information to go on than previously.

Finally I have been marking all the trivial little issues that I think we could fix, but are unlikely to be priorities. These are the kinds of things that if you were interested in helping out and getting started in developing for Mozilla you could start out on. Many will end up being a few lines of patch, just need to figure out where to put it and test it.

So if you are interested in tackling any of these please give it a go. You can find me on IRC (for reasons best left alone I appear as Mossop) or by email if you need any guidance on getting started. I’m going to try to keep this list updated as I find new bugs that fit there, I still have yet to go through all of the 263 confirmed bugs, maybe a job for next week.