development on Oxymoronical

Can't you do this faster with AI?

Mon, 09 Feb 2026 18:00:00 +0000

I’m hearing this question asked a lot lately. Both within Mozilla and from others in the industry. You come up with a plan for implementing some feature, put your best estimate on how long it will take to implement, and then you get push back from folks several levels removed from the project along the lines of “Wouldn’t this be faster if you used AI?”, or “Can’t Claude Code do most of this?”.

Making a case sensitive directory on Windows and macOS

Thu, 05 Jun 2025 08:53:00 +0100

Now that Firefox has switched to git as its canonical source code repository a number of us have been longing for all the nice features that Mercurial used to provide that are much more awkward with git. So many of us have been experimenting with Jujutsu which provides a lot of what is missing. It’s pretty good, I recommend giving it a go if you are also forced to use git!

But it has an annoying bug. If you’re on a case insensitive filesystem (the default on macOS and Windows) and a change renames a file in a way that only changes the case of the filename then Jujutsu gets confused. I think what’s going on is when it tries to apply the change it tells the OS to rename the file and then the OS sees that the filename is the “same” and does nothing. Subsequently Jujutsu constantly thinks there is a change because the filename on disk doesn’t exactly match what it expects and everything gets messy. The workaround is to manually rename those files to the correct names but that is annoying. I don’t know if Mozilla are particularly bad at this but the two examples in the issue are us and another just landed recently 😂.

Some thoughts on coding with AI

Sat, 24 May 2025 20:17:00 +0100

As you probably know AI tools are here and expectations range from “This is going to destroy the environment and make everyone unemployed” to “This is going to usher in a golden age freeing humanity from drudgery”. The reality is of course somewhere between the two and I don’t think we’re really going to know exactly where for many years.

I believe strongly in learning and understanding the tools available to us so that we can make pragmatic choices about what tools to use when. So for quite a while I’ve made various attempts to try using AI for coding. Most of my attempts have involved going to ChatGPT and asking it to write some code for me or answer questions about API specs. And it’s never been a great experience. Generally the code it generated wouldn’t work and it would confidently lie about what specs required. Clearly some people find this useful but I’ve never quite found out why yet.

Tests don't replace Code Review

Wed, 01 May 2024 23:02:00 +0100

I frequently see a bold claim come up in tech circles. That as a team you’re wasting time by doing code reviews. You should instead rely on automated tests to catch bugs. This surprises me because I can’t imagine anyone thinking that such a blanket statement is true. But then most of the time this is brought up in places like Twitter where nuance is impossible and engagement farming is rife. Still it got me thinking about why I think code review is important even if you have amazing tests.

Using VS Code for merges in Mercurial

Tue, 06 Sep 2022 17:33:53 +0000

I’ve always struggled to find a graphical merge tool that I can actually understand and up until now I have just been using merge markers along with a handy Mercurial command to open all conflicted files in VS Code, my editor of preference.

Well it turns out that since version 1.69 VS Code now has built in support for acting as a merge tool and after trying it out I actually found it to be useful! Given that they (and the rest of the world) tend to focus on Git I couldn’t find explicit instructions for setting it up for Mercurial so here is how you do it. Add the following to your ~/.hgrc:

Announcing LocalNS

Mon, 02 May 2022 20:07:21 +0000

I mess around with a bunch of different projects in my spare time but it’s been a long time since I’ve thought one was worth tidying up into an actual release. Maybe it will be useful to you?

The problem I faced was that I had a whole bunch of services that I installed on my network, some in docker, some as standalone servers, some behind a Traefik proxy. In the docker case I was using macvlan networking so each service had its own IP address accessible to the entire network. Once I learned how to do all that it became trivial to spin up a new local service, say InfluxDB or Grafana with a couple of lines in a docker-compose file.

Creating HTML content with a fixed aspect ratio without the padding trick

Wed, 30 Oct 2019 10:01:09 +0000

It seems to be a common problem, you want to display some content on the web with a certain aspect ratio but you don’t know the size you will be displaying at. How do you do this? CSS doesn’t really have the tools to do the job well currently (there are proposals). In my case I want to display a video and associated controls as large as possible inside a space that I don’t know the size of. The size of the video also varies depending on the one being displayed.

A simple command to open all files with merge conflicts

Wed, 09 Oct 2019 10:28:19 +0000

When I get merge conflicts in a rebase I found it irritating to open up the problem files in my editor, I couldn’t find anything past copying and pasting the file path or locating it in the source tree. So I wrote a simple hg command to open all the unresolved files into my editor. Maybe this is useful to you too?

[alias]
unresolved = !$HG resolve -l "set:unresolved()" -T "{reporoot}/{path}\0" | xargs -0 $EDITOR

Please watch your character encodings

Wed, 10 Jul 2019 13:38:01 +0000

I started writing this as a newsgroup post for one of Mozilla’s mailing lists, but it turned out to be too long and since this part was mainly aimed at folks who either didn’t know about or wanted a quick refresher on character encodings I decided to blog it instead. Please let me know if there are errors in here, I am by no means an expert on this stuff either and I do get caught out sometimes!

Welcoming a new Firefox/Toolkit peer

Wed, 13 Feb 2019 12:49:39 +0000

Please join me in welcoming Bianca Danforth to the set of peers blessed with reviewing patches to Firefox and Toolkit. She’s been doing great work making testing experiment extensions easy and so it’s time for her to level-up.

Taming Phabricator

Tue, 19 Jun 2018 10:31:08 +0000

So Mozilla is going all-in on Phabricator and Differential as a code review tool. I have mixed feelings on this, not least because it’s support for patch series is more manual than I’d like. But since this is the choice Mozilla has made I might as well start to get used to it. One of the first things you see when you log into Phabricator is a default view full of information.

Searchfox in VS Code

Thu, 07 Jun 2018 12:21:13 +0000

I spend most of my time developing flipping back and forth between VS Code and Searchfox. VS Code is a great editor but it has nowhere near the speed needed to do searches over the entire tree, at least on my machine. Searchfox on the other hand is pretty fast. But there’s something missing. I usually want to search Searchfox for something I found in the code. Then I want to get the file I found in Searchfox open in my editor.

Even more new peers

Wed, 20 Sep 2017 10:33:08 +0000

Please welcome the latest new peers to Firefox and Toolkit:

Johann Hofmann
Nihanth Subramanya

As you might gather I’ve been updating the peer list a lot lately trying to catch up with reality. If there is anyone I’m missing then please let me know!

How do you become a Firefox peer? The answer may surprise you!

Wed, 13 Sep 2017 11:02:42 +0000

So you want to know how someone becomes a peer? Surprisingly the answer is pretty unclear. There is no formal process for peer status, at least for Firefox and Toolkit. I haven’t spotted one for other modules either. What has generally happened in the past is that from time to time someone will come along and say, “Oh hey, shouldn’t X be a peer by now?” to which I will say “Uhhh maybe! Let me go talk to some of the other peers that they have worked with”. After that magic happens and I go and update the stupid wiki pages, write a blog post and mail the new peers to congratulate them.

New Firefox and Toolkit module peers

Tue, 12 Sep 2017 14:44:03 +0000

Please join me in welcoming another set of brave souls willing to help shepherd new code into Firefox and Toolkit:

Luke Chang
Ricky Chien
Luca Greco
Kate Hudson
Tomislav Jovanovic
Ray Lin
Fischer Liu

While going through this round of peer updates I’ve realised that it isn’t terribly clear how people become peers. I intend to rectify that in a coming blog post.

New Firefox and Toolkit module peers in Taipei!

Wed, 09 Aug 2017 16:05:13 +0000

Please join me in welcoming three new peers to the Firefox and Toolkit modules. All of them are based in Taipei and I believe that they are our first such peers which is very exciting as it means we now have more global coverage.

Tim Guan-tin Chien
KM Lee Rex
Fred Lin

I’ve blogged before about the things I expect from the peers and while I try to keep the lists up to date myself please feel free to point out folks you think may have been passed over.

Thoughts on the module system

Thu, 13 Jul 2017 15:06:04 +0000

For a long long time Mozilla has governed its code (and a few other things) as a series of modules. Each module covers an area of code in the source and has an owner and a list of peers, folks that are knowledgeable about that module. The full list of modules is public. In the early days the module system was everything. Module owners had almost complete freedom to evolve their module as they saw fit including choosing what features to implement and what bugs to fix. The folks who served as owners and peers came from diverse areas too. They weren’t just Mozilla employees, many were outside contributors.

More new Firefox/Toolkit peers

Thu, 23 Feb 2017 09:51:28 +0000

A few things are happening which means there are a bunch of new Firefox/Toolkit peers to announce.

First since I’m now owner of both Firefox and Toolkit I’ve decided it doesn’t make much sense to have separate lists of peers. Either I trust people to review or I don’t so I’m merging the lists of peers for these modules. Practically since Toolkit already included all of the Firefox peers this just means that the following folks are now Firefox peers in addition to already being Toolkit peers:

Welcome to a new Firefox/Toolkit peer, Shane Caraveo

Tue, 21 Feb 2017 09:49:38 +0000

It’s that time again when I get to announce a new Firefox/Toolkit peer. Shane has been involved with Mozilla for longer than I can remember and recently he has been doing fine work on webextensions including the new sidebar API. As usual we probably should have made Shane a peer sooner so this is a case of better late than never.

I took a moment to tell Shane what I expect of all my peers:

hgchanges is down, probably for good

Mon, 06 Feb 2017 14:01:35 +0000

My little tool to help folks track when changes are made to files or directories in Mozilla’s mercurial repositories has gone down again. This time an influx of some 8000 changesets from the servo project are causing the script that does the updating to fail so I’ve turned off updating. I no longer have any time to work on this tool so I’ve also taken it offline and don’t really have any intention to bring it back up again. Sorry to the few people that this inconveniences. Please go lobby the engineering productivity folks if you still need a tool like this.

On Firefox module ownership

Wed, 14 Dec 2016 16:15:24 +0000

It has been over eleven years since I first wrote a patch for Firefox. It was reviewed by the then-Firefox module owner, Mike Connor. If you had told me then that at some point in the future I was going to be the module owner I probably would have laughed at you. I didn’t know at the time how much Mozilla would shape my life. Yet yesterday Dave Camp handed over the reigns to me and here we are.

A new owner for the add-ons manager

Mon, 15 Aug 2016 16:29:33 +0000

I’ve been acting as the owner for the add-ons manager for the past little while and while I have always cared a lot about the add-ons space it is time to formerly pass over the torch. So I was pleased that Rob Helmer was willing to take it over from me.

Rob has been doing some exceptional work on making system add-ons (used as part of the go faster project) more robust and easier for Mozilla to use. He’s also been thinking lot about improvements we can make to the add-ons manager code to make it more friendly to approach.

Improving the performance of the add-ons manager with asynchronous file I/O

Wed, 27 Jan 2016 12:35:25 +0000

The add-ons manager has a dirty secret. It uses an awful lot of synchronous file I/O. This is the kind of I/O that blocks the main thread and can cause Firefox to be janky. I’m told that that is a technical term. Asynchronous file I/O is much nicer, it means you can let the rest of the app continue to function while you wait for the I/O operation to complete. I rewrote much of the current code from scratch for Firefox 4.0 and even back then we were trying to switch to asynchronous file I/O wherever possible. But still I used mostly synchronous file I/O.

Linting for Mozilla JavaScript code

Fri, 18 Dec 2015 11:27:07 +0000

One of the projects I’ve been really excited about recently is getting ESLint working for a lot of our JavaScript code. If you haven’t come across ESLint or linters in general before they are automated tools that scan your code and warn you about syntax errors. They can usually also be set up with a set of rules to enforce code styles and warn about potential bad practices. The devtools and Hello folks have been using eslint for a while already and Gijs asked why we weren’t doing this more generally. This struck a chord with me and a few others and so we’ve been spending some time over the past few weeks getting our in-tree support for ESLint to work more generally and fixing issues with browser and toolkit JavaScript code in particular to make them lintable.

Running ESLint on commit

Fri, 18 Dec 2015 11:24:23 +0000

ESLint becomes the most useful when you get warnings before even trying to land or get your code reviewed. You can add support to your code editor but not all editors support this so I’ve written a mercurial extension which gives you warnings any time you commit code that fails lint checks. It uses the same rules we run elsewhere. It doesn’t abort the commit, that would be annoying if you’re working on a feature branch but gives you a heads up about what needs to be fixed and where.

Delivering Firefox features faster

Mon, 05 Oct 2015 11:20:28 +0000

Over time Mozilla has been trying to reduce the amount of time between developing a feature and getting it into a user’s hands. Some time ago we would do around one feature release of Firefox every year, more recently we’ve moved to doing one feature release every six weeks. But it still takes at least 12 weeks for a feature to get to users. In some cases we can speed that up by landing new things directly on the beta/aurora branches but the more we do this the harder it is for release managers to track the risk of shipping a given release.

Making communicating with chrome from in-content pages easy

Mon, 23 Mar 2015 08:34:24 +0000

As Firefox increasingly switches to support running in multiple processes we’ve been finding common problems. Where we can we are designing nice APIs to make solving them easy. One problem is that we often want to run in-content pages like about:newtab and about:home in the child process without privileges making it safer and less likely to bring down Firefox in the event of a crash. These pages still need to get information from and pass information to the main process though, so we have had to come up with ways to handle that. Often we use custom code in a frame script acting as a middle-man, using things like DOM events to listen for requests from the in-content page and then messaging to the main process.

hgchanges is back up

Thu, 29 Jan 2015 10:33:05 +0000

The offending changeset that broke hgchanges yesterday turns out to be a merge from an ancient branch to current tip. That makes the diff insanely huge which is why things like hgweb were tripping over it. Kwierso point out that just ignoring those changesets would solve the problem. It’s not ideal but since in this case they aren’t useful changesets I’ve gone ahead and done that and so hgchanges is now updating again.

hgchanges is down for now

Wed, 28 Jan 2015 21:23:31 +0000

My handy tool for tracking changes to directories in the mozilla mercurial repositories is going to be broken for a little while. Unfortunately a particular changeset seems to be breaking things in ways I don’t have the time to fix right now. Specifically trying to download the raw patch for the changeset is causing hgweb to timeout. Short of finding time to debug and fix the problem my only solution is to wait until that patch is old enough that it no longer attempts to index it. That could take a week or so.

Welcome to the new Toolkit peers - Paolo, Matt, Jared and Irving

Tue, 15 Apr 2014 13:38:01 +0000

Slightly belated in some cases but I’d like to formally welcome four new toolkit peers. Paolo Amadini, Matthew Noorenberghe, Jared Wein and Irving Reid have all shown themselves to be well capable of reviewing patches in any of the toolkit code. Paolo, Matt and Jared actually got added a few months ago but apparently I failed to make an announcement at the time. Irving was added just last week. Please congratulate them all and don’t go too hard on their review queues!

An update for hgchanges

Thu, 13 Mar 2014 15:47:18 +0000

Nearly a year ago I showed off the first version of my webapp for displaying recent changes in mercurial repositories. I’ve heard directly from a number of people that use it but it’s had a few problems that I’ve spent some of my spare time trying to solve. I’m now pleased to say that a new version is up and running. I’m not sure it’s accurate to call this a rewrite since it was entirely incremental but when I look back over of the code changes there really isn’t much that wasn’t touched in some way or other. So what’s new? For you, a person using the site absolutely nothing! So what on earth have I been doing rewriting the code?

Developer Tools meet-up in Portland

Wed, 05 Mar 2014 14:33:06 +0000

Two weeks ago the developer tools teams and a few others met in the Portland office for a very successful week of discussions and hacking. The first day was about setting the stage for the week and working out what everyone was going to work on. Dave Camp kicked us off with a review of the last six months in developer tools and talked about what is going to be important for us to focus on in 2014. We then had a little more in-depth information from each of the teams. After lunch a set of lightning talks went over some projects and ideas that people had been working on recently.

An editable box model view in the devtools

Fri, 21 Feb 2014 15:07:24 +0000

This week the whole devtools group has been sequestered in Mozilla’s Portland office having one of our regular meet-ups. As always it’s been a fantastically productive week with lots of demos to show for it. I’ll be writing a longer write-up later but I wanted to post about what I played with over the week.

My wife does the odd bit of web development on the side. For a long time she was a loyal Firebug user and a while ago I asked her what she thought of Firefox’s built in devtools. She quickly pointed out a couple of features that Firebug had that Firefox did not. As I was leaving for this week I mentioned I’d be with the devtools group and she asked whether her features had been fixed yet. It turns out that colour swatches had been but the box model still wasn’t editable. So I figured I could earn myself some brownie points by hacking on that this week.

Firefox now ships with the add-on SDK

Wed, 15 May 2013 15:31:59 +0000

It’s been a long ride but we can finally say it. This week Firefox 21 shipped and it includes the add-on SDK modules.

What does this mean? Well for users it means two important things:

Smaller add-ons. Since they no longer need to ship the APIs themselves add-ons only have to include the unique code that makes them special. That’s something like a 65% file-size saving for the most popular SDK based add-ons, probably more for simpler add-ons.
Add-ons will stay compatible with Firefox for longer. We can evolve the modules in Firefox that add-ons use so that most of the time when changes happen to Firefox the modules seamlessly shift to keep working. There are still some cases where that might be impossible (when a core feature is dropped from Firefox for example) but hopefully those should be rare.

To take advantage of these benefits add-ons have to be repacked with a recent version of the SDK. We’re working on a plan to do that automatically for existing add-ons where possible but developers who want to get the benefits right now can just repack their add-ons themselves using SDK 1.14 and using cfx xpi --strip-sdk, or using the next release of the SDK, 1.15 which will do that by default.

Get notifications about changes to any directory in mercurial

Fri, 05 Apr 2013 14:36:32 +0000

Back in the old days when we used CVS of all things for our version control we had a wonderful tool called bonsai to help query the repository for changes. You could list changes on a per directory basis if you needed which was great for keeping an eye on certain chunks of code. I recall there being a way of getting an RSS feed from it and I used it when I was the module owner of the extension manager to see what changes were landed that I hadn’t noticed in bugs.

Hacking on Tilt

Mon, 18 Mar 2013 18:38:42 +0000

Tilt, or 3D view as it is known in Firefox, is an awesome visual tool that really lets you see the structure of a webpage. It shows you just how deep your tag hierarchy goes which might give signs of your page being too complex or even help you spot errors in your markup that you wouldn’t otherwise notice. But what if it could do more? What if there were different ways to visualise the same page? What if even web developers could create their own visualisations?

The Add-on SDK is now in Firefox

Fri, 01 Feb 2013 22:06:43 +0000

We’re now a big step closer to shipping the SDK APIs with Firefox and other apps, we’ve uplifted the SDK code from our git repository to mozilla-inbound and assuming it sticks we will be on the trains for releasing. We’ll be doing weekly uplifts to keep the code in mozilla-central current.

What’s changed?

Not a lot yet. Existing add-ons and add-ons built with the current version of the SDK still use their own versions of the APIs from their XPIs. Add-ons built with the next version of the SDK may start to try to use the APIs in Firefox in preference to those shipped with the XPI and then a future version will only use those in Firefox. We’re also talking about the possibility of making Firefox override the APIs in any SDK based add-on and use the shipped ones automatically so the add-on author wouldn’t need to do anything.

Making Git play nice on Windows

Fri, 28 Dec 2012 17:57:13 +0000

A while ago now I switched to Windows on my primary development machine. It’s pretty frustrating particularly when it comes to command line support but MozillaBuild goes a long way to giving me a more comfortable environment. One thing that took a long time to get working right though was full colour support from both mercurial and git. Git in particular is a problem because it uses a custom version of MSYS which seems to conflict with the stock MSYS in MozillaBuild leaving things broken if you don’t set it up just right. Since I just switched to a new machine I thought it would be useful to record how I got it working, perhaps more for my benefit than anything else, but perhaps others will find it useful too.

Let's just put it in Toolkit!

Fri, 23 Nov 2012 23:41:56 +0000

Toolkit is fast turning into the dumping ground of mozilla-central. Once upon a time the idea was simple. Any code that could be usefully shared across multiple applications (and in particular code that wasn’t large enough to deserve a module of its own) would end up in Toolkit. The rules were pretty simple, any code in there should work for any application that wants to use it. This didn’t always work exactly according to plan but we did our best to fix Seamonkey and Thunderbird incompatibilities as they came along.

What is an API?

Fri, 23 Nov 2012 19:27:02 +0000

I recently posted in the newsgroups about a concern over super-review. In some cases patches that seem to meet the policy aren’t getting super-reviewed. Part of the problem here is that the policy is a little ambiguous. It says that any API or pseudo-API requires super-review but depending on how you read that section it could mean any patch that changes the signature of a JS function is classed as an API. We need to be smarter than that. Here is a straw-man proposal for defining what is an API:

Simple image filters with getUserMedia

Mon, 22 Oct 2012 17:44:37 +0000

I forgot to blog about this last week, but Justin made me remember. The WebRTC getUserMedia API is available on the Nightly and Aurora channels of Firefox right now and Tim has done a couple of great demos of using JavaScript to process the media stream. That got me interested and after a little playing around I remembered learning the basics of convolution image filters so I thought I’d give it a try. The result is a sorta ugly-looking UI that lets you build your own image filters to apply to the video coming off your webcam. There are a few pre-defined filter matrices there to get you started and it’s interesting to see what effects you can get. Remember that you need to enable media.navigator.enabled in about:config to make it work.

Managing changes is the key to a project's success

Wed, 30 May 2012 07:43:15 +0000

TomTom made an interesting claim recently. Their summary is “when it comes to automotive-grade mapping, open source has some quite serious limitations, falling short on the levels of accuracy and reliability required for safe navigation”

This is a bold claim and they talk about recent studies that back them up. Unfortunately none of them are referenced but it’s pretty clear from the text of the article that all they are doing is comparing the accuracy of TomTom maps with existing open source maps. So they’re just generalising, this doesn’t prove a limitation with the open source process itself of course, just perhaps of a particular instance of it.

How Crashplan breaks xpcshell tests on Windows

Wed, 23 Nov 2011 20:15:52 +0000

I recently switched to a Windows laptop and have been going through the usual teething pains related. One thing that confused me though was that when I was running xpcshell tests on my new machine they would frequently fail with access denied errors. I’ve seen this sort of thing before so I know some service was monitoring files and opening them after they had changed, when this happens they can’t be deleted or edited until the service closes them again and often tests open, close and delete files so fast that there isn’t time for that to happen.

WebApp Tabs, version control and GitHub

Mon, 07 Nov 2011 00:59:28 +0000

The extension I’ve been working on in my spare time for the past couple of weeks is now available as a first (hopefully not too buggy) release. It lets you open WebApps in Thunderbird, properly handling loading new links into Firefox and making all features like spellchecking work in Thunderbird (most other extensions I found didn’t do this). You can read more about the actual extension at its homepage.

Overlays without overlays in restartless add-ons

Mon, 31 Oct 2011 01:43:46 +0000

Perhaps the most common way of making changes to Firefox with an extension has always been using the overlay. For a window’s UI you can make changes to the underlying XUL document, add script elements to be executed in the context of the normal window’s code and add new stylesheets to the window to change how the UI looks.

Restartless add-ons change this around completely, the normal overlay and style-overlay mechanisms just aren’t available to restartless add-ons and this is likely to remain true for a while, these methods don’t clean up after themselves when the add-on is uninstalled.

Adding add-on preferences to the Add-ons Manager

Thu, 07 Jul 2011 19:06:32 +0000

For some time now Firefox for mobile has had this nice feature where add-ons could embed their preferences right into the list of add-ons, no need to open a whole a new window like add-ons for desktop have to. During the development of Firefox 4 we were a little jealous of what the mobile team had done and so we drew up some ideas for how the same functionality would look on desktop. We didn’t get time to implement them then but I’m excited that someone from the community stepped up and implemented it for us. Not just that but he made the code shared between mobile and desktop, added some new option types and made it work fine for restartless add-ons which are unable to register their own chrome.

Unloading JS modules

Thu, 07 Jul 2011 18:26:44 +0000

One of the problems with writing a restartless add-on is that you have to be careful about undoing anything your add-on does when it is told to shutdown. This means that right now some features of the platform can’t be used as we have no way to undo them. Recently I made this list a little shorter by making it possible to unload JS modules loaded with Components.utils.import().

Just call Components.utils.unload(uri) and the module loaded from that URI will be unloaded. Take care when you do this because something might still have references into it which will stop working. Firefox also caches the module’s code for fast loading the next time around. The add-ons manager clears this cache when your add-on is updated or uninstalled so you mostly don’t have to worry about it but if you do something strange like unload a module, manually alter the file and then import it again you won’t get the latest code.

Why do Firefox updates break add-ons?

Sat, 25 Jun 2011 00:25:22 +0000

Our success in switching to the new rapid release cycle for Firefox has stirred up lots of excitement in the community and I wouldn’t be surprised if that intensifies when we ship the next update to Firefox in 8 weeks time. People keep pointing out that everytime we update Firefox we break add-ons so surely faster releases means add-ons will get broken faster. Many people don’t really understand why Firefox updates should break add-ons anyway so here is my attempt at an explanation and how maybe rapid releases aren’t such a bad thing after all.

Creating custom add-on types just got easier

Wed, 25 May 2011 19:01:53 +0000

One of the nice features that we added to the add-ons manager in Firefox 4 was support for custom add-on types that could be treated the same way as the built-in types, even showing up in the same UI if you did a little work. I blogged a basic example of how to do this and I know since then Greasemonkey and Stylish have been using the support.

How to disable extension compatibility checking on Nightly builds of Firefox

Tue, 24 May 2011 22:26:58 +0000

A long long time ago (I can still remember…) we changed the preference you use to disable compatibility checking for extensions. We still aim for users to instead use tools like the Add-on Compatibility Reporter to handle this (especially since we are going to start crowdsourcing data from it), but for developers who don’t want to install that but still want to use extensions on their nightly builds the new rapid release model would mean setting a new preference every 6 weeks.

What's next for the Add-ons Manager?

Tue, 08 Mar 2011 22:52:14 +0000

Firefox 4 is just around the corner and it’s great to look back over just how far the Add-ons Manager has come since Firefox 3.6. In fact if you want to see the full history look at my earlier post that shows its evolution since Phoenix 0.2. We set out with some pretty lofty goals for Firefox 4 and I’m pretty excited at just how many of them we achieved. I hope everyone appreciates the hard work that Blair, Boriss, Justin, Henrik, Ben, myself and all the others put in to get us to where we are today.

Playing with windows in restartless (bootstrapped) extensions

Wed, 19 Jan 2011 20:14:27 +0000

Lots of people seem to be playing with the new support for restartless extensions (also known as bootstrapped extensions) coming in Firefox 4. Nothing could make me happier really. I’m not sure I can remember ever helping implement something which is will hopefully turn out to be a game changer for extension development in the future. The technical details of restartless extensions are talked about in a few places but one thing that is missing is what I think is probably going to be the most common code pattern in these extensions.

Firefox 4 and the Add-ons Manager at Add-on-Con

Fri, 10 Dec 2010 04:52:05 +0000

As I mentioned before I was part of a presentation at Add-on-Con this year. Myself, Boriss and Justin talked about the new UI changes in Firefox 4 and about the main changes to the add-ons manager. If you’re particularly interested the slides are available here though I guess slides are often just tiny snippets of info from the actual session so if anything catches your eye you’ll need to get in touch and ask us about it.

Add-on-Con is here!

Fri, 03 Dec 2010 22:32:06 +0000

Next week is Add-on-Con 2010 and if you do any work in the add-ons space then you’re probably going to want to take a look at what is going on and hopefully sign up to attend. There are two days this year, one for some training and then the traditional day for keynotes and business/development tracks. I’ll be there for all of the main day and while I don’t think I am going to make the training day I should be there in the evening for the Mozilla party, be sure to sign up.

Minor change coming to the interface amIWebInstallListener in Firefox 4.0 beta 8

Thu, 25 Nov 2010 00:27:48 +0000

We’re past API freeze so any API changes should be getting announced and communicated. In this case the change is tiny and unlikely to affect anyone. Have you heard of the interface amIWebInstallListener? If not then you can probably ignore this.

If you’re interested it is effectively what the add-ons manager backend code uses to communicate messages about webpage initiated add-on installations. An add-on or application might provide its own implementation if it wanted to provide its own UI for installs. Or an add-on might call it to get the normal UI to show up for some other cases but this is pretty rare.

PreFox is now available for testing

Sun, 19 Sep 2010 04:30:02 +0000

I’ve finally been able to make some early alpha builds of PreFox, which is clearly a rather unoriginal name for Firefox running on the Palm Pre, available for testing. You can read more and find the builds at the release announcement.

This has been a long time coming, made that much longer by Sprint delaying the release of webOS 1.4.5 and of course Firefox 4 blockers eating into my spare time, I’m hopeful that now both builds and the source code are available some people will start to help out with getting it to be a viable alternative to the default webOS browser. Lots of the remaining work is stuff that is really outside my skill-set.

Don't miss an exciting opportunity to shape the future of Firefox 4!

Wed, 01 Sep 2010 23:31:11 +0000

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.

How to extend the new Add-ons Manager (or how I built a simple greasemonkey clone in an evening)

Fri, 09 Jul 2010 22:30:56 +0000

One of the goals of the new add-ons manager API was to create something that was itself extensible. A couple of times in the past we’ve had to add new types of add-ons to the UI like Plugins and Personas. In both cases squeezing them into the UI was something of a kludge involving a bunch of custom code for each case. We already have a number of new types of add-ons that we want to add, things like search plugins which are currently managed by their own custom UI.

Multiple breaking changes are coming for components in extensions

Mon, 14 Jun 2010 23:45:50 +0000

Are you an extension or application developer? Have you written any XPCOM components, JS, binary or otherwise? If not you can probably ignore the rest of this post, unless you are interested anyway.

If you do then you might be interested to hear that your components are probably going to break in an upcoming Firefox nightly, maybe as early as next week. I’m going to blog specific examples on the changes you need to make once we have better documentation up and builds to test against, for now it is just important for you to know that the changes are coming.

Documenting the new Add-ons Manager

Fri, 04 Jun 2010 16:35:24 +0000

I’ve spent some time this week transferring all the API documentation for the new add-ons manager from the Mozilla wiki to the Mozilla Developer Network. This should now be the place to go for the definitive info.

Right now it is pretty dry, for the most part just pure API info with no examples. Before I started working more on that side of things I wanted to ask what kind of examples people might like to see documented?

Support for dropping XPI files into the extension install locations might be going away

Thu, 27 May 2010 23:22:05 +0000

For some time now Firefox has supported a way of installing extensions that involves simply copying the extension’s XPI file into one of the extension install locations. The next time Firefox runs it would pop up the install dialog for the extension and allow the user to choose whether to install it or not.

I don’t know how many people use this feature and while the code to do it (at least for the profile folder) isn’t terribly complex, it is additional code that may not be necessary. Right now the new add-ons manager doesn’t support it and I’ve heard only a couple of people comment on its absence but nightly testers are by no means representational so I’m asking a little more widely whether people have a real need for keeping this working in Firefox 4?

Where is the updated Nightly Tester Tools?

Mon, 17 May 2010 02:39:00 +0000

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.

Add-ons manager re-landed

Mon, 10 May 2010 23:36:46 +0000

A little sort of coincidental performance regression forced us to back out the new add-ons manager last week. It has now been re-landed with added bug fixes and should be in tomorrow’s nightly.

The new add-ons manager is here

Thu, 29 Apr 2010 19:34:24 +0000

Finally, after far too much time, the new add-ons manager is about to land in trunk nightlies. I am putting together the final patches to land now. The bit most people will see is the new UI so I guess I’ll steal Boriss’ image for you to look at here with the same caveats. What you see on trunk over the next few days is just the initial steps to switching to a redesigned UI and (more importantly from my point of view) a totally new extension manager backend that will make it easier for us to improve and build upon in the future. The changes are so large that it is important to get more people testing it now while it still looks fairly unpolished so we can pick up problems that we’ve missed.

Myths and mysconceptions about Firefox on the Palm Pre

Wed, 21 Apr 2010 18:09:49 +0000

Since I posted last week about how I was experimenting with running Firefox on my Palm Pre a number of tech news sites, large and small, picked it up and posted their own take on it. Some of the sites (and some of the readers of those sites) made some fairly odd statements about my work. This is probably because to the uninitiated (and many of the initiated in fact) the internals of Firefox are something of a mystery. I also suspect I made a couple of poor choices of words which led to some misunderstandings so I’d like to try to clarify a couple of points that might make it easier to understand what is going on.

Firefox running on the Palm Pre (mostly)

Mon, 12 Apr 2010 23:02:56 +0000

One of the first things I did when I moved to the U.S. was to get myself a smartphone, and that phone was the Palm Pre. I’ve always thought it was way ahead of its competition in terms of the potential of its potential capabilities and platform. Sadly I think it is let down some by build quality and hardware issues, but I still love it as a phone and really hope that if Palm get bought they’ll continue work on it and develop a better 2nd gen version.

How do restartless add-ons work?

Mon, 12 Apr 2010 21:41:48 +0000

I blogged a short time ago about how we’re adding support for a new form of add-on to Firefox that can install and uninstall without needing to restart the application. Since then I’ve been finalizing a specification for how the platform will load these add-ons, trying to keep it simple but still give developers everything they commonly need. The planned specification is now available and if developers have comments then I’d like to hear them. Currently there isn’t a version of Firefox that implements it but that should change in the next day or so when I make the changes to the add-ons manager project branch and very soon when it all lands on trunk.

How we're breaking some extensions in the near future

Fri, 19 Mar 2010 22:09:31 +0000

You may have read some reports about how we’re re-implementing the bulk of the extension manager in Firefox. It’s been a long running project (something like a year since I first really started planning how to do it). Things are finally started to come together and all being well we are likely to look at landing the first pieces of this on the trunk nightlies in as little as a weeks time. I’ll be up front, this isn’t going to be a perfect landing. There may be some thing that are missing and other bits where the user experience isn’t as perfect as it will be finally. Of course there may also be bugs we have to rush to fix. Despite all this we feel that we’re about at the point where exposing it to the hands of thousands of nightly testers is the best way forward. Your eyes spot things that we miss, even things that may seem obvious to you and you’re vital to us getting these sorts of features polished and really just how they should be before they get released to the world at large in a Firefox release.

Look Ma, no restarts!

Sun, 14 Mar 2010 22:05:11 +0000

Look Ma, no restart!

This is a screenshot of some of my latest (and most exciting) work on my project to rewrite the extension manager. I’ve just implemented support for a special kind of extension that can install (and uninstall, and enable, disable, upgrade and anything else you can think of) without the user needing to restart Firefox. This is of course to allow add-ons developed on the Jetpack platform to install without restarts but the feature is going to be available to any extension author, there are just some restrictions to how these extensions work.

Simplifying

Sat, 13 Mar 2010 02:29:49 +0000

The big project that I have been working on for quite some time now is a complete change to the architecture of the add-ons manager backend. It’s a big scary prospect since (IMHO) the code is pretty crucial to the success of Firefox and many other Mozilla based applications. Without extensions I don’t think we’d be where we are today, in fact it was because of extensions that I got involved in the project in the first place.

Broken executables in extensions in Firefox 3.6

Fri, 22 Jan 2010 18:09:41 +0000

If you are an extension developer and include executable files in your XPI package (binary or shell scripts) then you may be seeing problems in Firefox 3.6.

Back between Firefox 3.6 beta and Firefox 3.6 RC we took a small fix to the extension manager that changed how we extract the files from the XPI package. The fix involved adjusting how we accessed files to avoid hitting problems with certain anti-virus tools that would occasionally lock files in the middle of extraction making us fail to install the add-on. A side effect to this fix leaves us setting file permissions on the extracted files in a slightly different way to previously. This side effect means that the executable permission is getting stripped from all extracted files. If you try to execute these files with nsIProcess it will likely fail.

Throwing xpcom docs out into the wild

Tue, 19 Jan 2010 19:50:41 +0000

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.

Do we need extension dependencies?

Thu, 07 Jan 2010 18:50:42 +0000

Ever since Firefox 2 we have vaguely supported a form of extension dependency. That is marking an extension as requiring particular versions of another extension.

The support is currently very limited and when a user tries to use an add-on that depends on something they don’t have they are pretty much left in the cold. While we tell them it requires something we don’t tell that what it requires or give them any easy way to download and install it.

Changing the checkCompatibility preference

Fri, 06 Nov 2009 21:31:18 +0000

Back in the mists of time I wrote some code to make nightly testers’ lives easier by giving them a simple preference to flip if they wanted to be able to install and use incompatible extensions. It’s been more than three years since then and the use of this preference has grown beyond its original use. It is now something recommended to regular users everywhere from forums to comments in news articles as a way to use their extensions in the new major Firefox releases.

Lightweight themes UI landed

Fri, 18 Sep 2009 22:11:27 +0000

As part of the ongoing work to bring basic support for lightweight themes (based on the ideas from the Personas extension) into Firefox 3.6 I’ve today landed the main UI parts that allow users to see and select between lightweight themes they have used recently. Dão landed most of the backend last week but we’re still waiting on the support for installing new lightweight themes before this feature will be truly usable in the development builds. For the time being here is a shot of what the UI looks like in the add-ons manager after you have used some lightweight themes.

Third-party extension installation status

Sat, 12 Sep 2009 16:04:05 +0000

I have been remiss in not posting a status update about this in two weeks, but that is mostly because we have unfortunately had to slow down work on this feature. The problem is that a string freeze became necessary for all toolkit code (the code shared with the Firefox mobile browser and where this feature would have lived). Unfortunately this all came up over a small period when I was travelling long distances and having to take time out to satisfy immigration authorities that I wasn’t a terrorist intent on bringing down the U.S. government.

Third-party add-on notification progress, the lite edition

Fri, 28 Aug 2009 23:36:12 +0000

This week has been the Firefox work week where almost all of the team, including me, made our way to Mountain View. This pretty much means that you spend the entire week in meetings since when you’re remote it can be hard to keep in sync on everything. Of course this means that the amount of coding is pretty low for the week so there isn’t a great deal of progress to report here.

Progress on notifying users about third-party add-ons

Fri, 21 Aug 2009 18:28:41 +0000

This is a weekly status update on the feature to notify users about add-ons that third-party installers have added to Firefox. You can read more about it in last weeks blog post or on the project wiki.

Status

There has been little progress this week mostly due to waiting to see whether the doorhanger notifications UI was going to arrive in time for Firefox 3.6. It looks like it isn’t so instead we are discussing using an in-content page to describe the add-ons that have been installed and allowing users to disable them.

Notifying users about third-party add-ons

Fri, 14 Aug 2009 21:48:52 +0000

You may have noticed many of the Firefox team starting to blog progress reports on Fridays. This is a part of our new plan to clearly define the main projects we are all working on and communicate a much as possible about them rather than just having users surprised to see them turn up in nightlies. So here is my report for this week:

I’ve been working on improving the level of information and control we give users over add-ons installed by other applications on the system (think Skype, Java, AV tools etc.). The work for this is being tracked in bug 476430 and on the project wiki.

Bumper XULRunner release day!

Wed, 22 Jul 2009 18:42:41 +0000

Thanks to the hard work of Nick Thomas and Lukas Blakk, today I can announce the availability of two new official releases of the XULRunner runtime and SDKs. XULRunner 1.9.0.12 is a maintenance release for the 1.9.0 branch (the code that matches Firefox 3.0.x). XULRunner 1.9.1 is the first official release of XULRunner on the 1.9.1 branch (which matches the code in Firefox 3.5.x). Unfortunately we’re not quite at the point of shipping XULRunner releases at the same time as Firefox 3.5.x releases, but we should have a 1.9.1.1 release soon.

Where is XULRunner 1.9.1?

Wed, 08 Jul 2009 19:49:04 +0000

A question I have been hearing quite a bit on IRC since Firefox 3.5 was released. We don’t quite have the build automation set up to do XULRunner 1.9.1 releases at the same time as Firefox yet, but Nick has been awesome and manually spun some release candidates. These should be pretty much good to go but it would be useful if anyone interested could try them out and report on any serious problems they see. Either just comment here or file a bug and mark it blocking bug 502915.

Moar xpcom docs!

Sun, 05 Jul 2009 17:57:03 +0000

While many of you were out blowing things up over the weekend I spent a few days varying between getting quite a bit done and banging my head against my desk in frustration.

First I updated the XPCOM interface lists that I have been working on with the final release version of Gecko 1.9.0. A few people had asked me for it but I had hit upon the problem that I had lost some of the arcane scripts that I was using to gather the data and so I had to rebuild them first. I have dropped information about the beta versions of 1.9.1 now, just because it was less work that way, if people desperately want them back then I can probably do it.

Farewell contents.rdf

Thu, 11 Jun 2009 13:09:17 +0000

This is mainly of interest to add-on and application developers and I should stress from the outset that this is talking about changes in Gecko 1.9.2 which will first be released in whatever version of Firefox comes in 6-12 months time. Firefox 3.5 is unaffected by this change.

What was it?

Contents.rdf was the old way of performing chrome registration for add-ons. It was replaced by chrome.manifest back in the mists of time in Gecko 1.8 and Firefox 1.5 (back in 2005 as it happens). We’ve continued to support reading contents.rdf for those developers who hadn’t had the chance to make the switch but after 4 years it seems time to remove that support and clean up the code that dealt with it.

Improving the add-on install experience

Wed, 03 Jun 2009 09:44:13 +0000

Add-on developers face a bit of a challenge when it comes to helping users get the most out of their add-ons. Even once you are past the first hurdle and have got a user to install the add-on, you then need to help them get up and running quickly after Firefox has restarted. Presented with just the blank Firefox window it can be difficult for a user to know where to go next. Many add-on developers have taken to including a first-run experience to give the user some help. Display a webpage with some instructions or open a wizard to start setting up. As this practice started it was generally acceptable. Few add-ons actually did anything so it was helpful. These days though many add-ons are doing it, no doubt with more to come. It is starting to be an annoyance in some cases. Others have already been discussing ways that we can improve this.

Why change is hard

Mon, 11 May 2009 10:56:21 +0000

This is really not the ideal set of interactions between the extension manager and its related components. Unfortunately changing it is going to be hard.

interdependencies

Unfortunately adding any new features is also pretty hard until at least some of these dependencies are broken.

XULRunner 1.9.2a1pre builds also available

Sat, 28 Mar 2009 01:23:34 +0000

Just as I’ve made some 1.9.1b3 builds I’ve spun some builds based on the latest trunk. Feel free to use these to see how things are shaping up with the bleeding edge Mozilla code. Obviously it is pre-alpha so not for productions.

Windows runtime sdk
Linux runtime sdk
Mac OSX universal runtime i386 sdk ppc sdk

XULRunner 1.9.1b3 builds, get them while they're hot

Fri, 27 Mar 2009 18:20:49 +0000

In the process of switching from CVS to Mercurial (and behind the scenes Tinderbox to Buildbot), quite a lot of Mozilla’s build and release systems have had to be updated. Sadly one of the casualties that has yet to be resuscitated are nightly builds of XULRunner on the 1.9.1 branch and trunk. Catlee is now doing some excellent work to get these up and running, but until that gets going here are some semi-official builds using the code matching Firefox 3.1b3. I say semi-official, they were built on regular build slaves using the standard configuration, but just done by hand. I also haven’t tested all of them yet so let me know if you hit any issues, they might be good indicators of issues we’ll see with the nightlies.

Testing the background update checks

Thu, 19 Mar 2009 13:02:36 +0000

Firefox does a fair number of things in the background to help keep things up to date. This includes checking for updates to Firefox itself, checking for updates to add-ons you have installed and checking for updates to a blocklist that disables known unstable add-ons. Normally it does these things quite happily, but for developers and QA, trying to verify that these background tasks are doing what they are supposed to can be annoying. After all who wants to leave Firefox running for a day just to see if it finds a new update?

Brussels bound

Wed, 04 Feb 2009 11:12:57 +0000

This weekend is FOSDEM 2009 and I’m actually managing to attend this year. It’s kind of weird, I keep doing all this travelling to the states yet I end up having to miss all the awesome stuff that goes on in Europe for various reasons (often because I am all travelled out from the states). But I’m going to be at FOSDEM even if it kills me, which considering the snow on the roads and serious travelling I have over the next few months is a possibility. Thankfully the jetlag from Europe is a lot easier to recover from.

Updated Interface lists

Thu, 29 Jan 2009 17:27:08 +0000

I’ve generated a new database for my interface listing webapp so you can now see the current state of the 1.9.1b3pre and 1.9.2a1pre platforms. So for all you extension developers getting ready for the Firefox 3.1b3 release maybe you want to see what has changed since 3.1b2? Or since 3.0?

There are still more things I want to do with this web-app, but right now my time is being spent elsewhere so for now I’ll just keep it up to date with the beta releases. Once 3.1 final is released I’ll likely remove all the beta versions since they probably won’t be necessary then.

Zooming along, hopefully as fast as before

Wed, 14 Jan 2009 19:43:14 +0000

I’ve just landed a fix to a bug that has irritated me ever since page zoom started getting remembered for sites. It fixes a real problem you find if you both use zoom a fair bit, and load pages in background tabs. When you finally decide to look at that tab there is this little pause (or long pause if the page is large) and sometimes a visual jump as it re-zooms the content. It also changes where the page is scrolled to which is very irritating if you have just clicked a link to a specific line in some source code for example.

What is the most useful way to present interface lists?

Mon, 01 Dec 2008 22:30:51 +0000

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:

Improving the API references

Sun, 16 Nov 2008 13:21:01 +0000

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.

API reference updates

Sat, 15 Nov 2008 20:29:20 +0000

Since my first announcement about my little api reference tool I’ve slowly been working on updates to make it more useful and easier to navigate around. I’ve now gone and pushed the latest version live. A few of the new features:

The main and platform lists of interfaces are split by the module where the interface lives.
Interface lists have a quick filter box, type in it to filter the list quickly.
Any interfaces used as return types or parameters are now links to get you straight to the information about them.
Full IDL support so it now lists all the special attributes and for the uninitiated they have tooltips that explain what they mean.
You can now list all usage of an interface by other interfaces.
Constants are ordered the same as in the source IDL since they tend to make more sense that way.
Includes direct links to the source IDL file.

I’ve also updated the database with the latest APIs in 1.9.1b2pre and as soon as 1.9.1b2 is frozen I’ll update it again just to be sure it has the latest versions.

Planning for the future

Tue, 28 Oct 2008 16:24:26 +0000

For some time now I’ve been throwing around ideas for new features that we may want for the add-ons manager. After lots of thought and trying to take on board comments from anyone that would pipe up I decided it was high time to put together an actual plan for what features I have decided should be pursued and what order to start tackling them.

The roadmap itself should be pretty self explanatory, just remember that nothing is ever set in stone. I’ll try to keep it updated as things change, features seem less important or new items are added. But for now this is how I see the add-ons manager evolving over the course of about the next year or so, which may be the next two versions after Firefox 3.1.

Finding API Changes

Fri, 24 Oct 2008 20:07:51 +0000

I started a small discussion on the newsgroups the other day wondering about the numbers of API changes that had landed on trunk since 1.9.0. It was a short discussion, maybe partly because all I had to go on were the vague metrics that mercurial could give me. It also evolved a little into a discussion of how add-on developers we’re meant to find out about API changes. It’s true that as developers we are getting better at trying to announce our changes as much as possible, but inevitably we miss some, and if you don’t track the announcements what then?

Frustration

Tue, 21 Oct 2008 18:07:02 +0000

For a while now I’ve been in a bit of a rut. I knew I was there I just hadn’t quite got the motivation to pull myself out of it. It wasn’t such a bad place to be, but the difference of being just ok with the way things are going and being exactly where you want to be and with the people you want to be with is a pretty large one. I’ve been exceptionally lucky that over the last few months a bunch of things have happened that will help take me to where I want to go and start some new and exciting changes in my life.

Why 2 SDKs are better than 1

Thu, 10 Apr 2008 19:30:42 +0000

In the past the Gecko SDK was somewhat limited. You could compile against it, but only if you were using frozen components, of which there are exceptionally few. You can build an application with only them, but I’d be startled if any moderately complicated app or extension gets by with only them. Thankfully this has changed for 1.9 and the new style SDK contains all interfaces and headers, frozen and unfrozen. This gives you access to lots more, though has the minor disadvantage that you have to keep an eye on what you are using as it could break in the future.

Mac Intel Gecko SDK

Sun, 13 May 2007 22:38:37 +0000

Update: Mozilla now produce intel gecko SDKs so there is no need to use the version I have put here, I’ll leave it for posterity though.

It’s currently a bit of a pain building xpcom components in intel macs. The only officially available sdk is ppc only. Until Mozilla come up with an official version, here is an intel build of it for those that want it: gecko-sdk-mac-intel-1.8.1.3.zip

As the name suggests it’s built against Gecko 1.8.1.3. To the best of my knowledge it’s right but please don’t bug me if you can’t get your component to work with it unless you’re pretty positive that it’s the sdk that’s wrong.