Categories
Mozilla

Bugzilla Helper Add-on

I’ve been a bit frustrated at how often I switch from my e-mail client to my browser when I’m reading bugmail to reply to some comment. Then I saw Gerv’s Bugzilla REST API, and I decided it was time to write an add-on.

Without further ado, I present the add-on. Feel free to give me feedback by leaving a comment on this post.

Categories
Mozilla

Native Code Tests Now Have an Automagic Profile Directory

Today I checked in bug 517604 which gives native code tests a new, clean profile directory after every run. This puts the native code test harness on par with xpcshell-tests, and tests will no longer have to provide their own profile directory. This means that they no longer have to clean up after themselves. The harness will do it for them now! Happy testing :)

Categories
Mozilla

XPCOMUtils API Addition

We’ve recently added two new API’s on XPCOMUtils that make a common coding pattern simpler to do. It is quite common to have “smart getters” to store a reference to a service that you use in JavaScript. Normally, folks write code that looks something like this:

this.__defineGetter__("_ioService", function() {
  delete this._ioService;
  return this._ioService = Components.classes["@mozilla.org/network/io-service;1"].
                           getService(Components.interfaces.nsIIOService);
});


That gets long and verbose if you have any more than a few of these getters. The new approach looks like this:

XPCOMUtils.defineLazyServiceGetter(this, "_ioService",
                                   "@mozilla.org/network/io-service;1",
                                   "nsIIOService");


The net result is a lot less boilerplate code, which, in my opinion, is a lot nicer to read. I’ve already converted the toolkit code in the Places module over, and the resulting code is much nicer.

Sometimes, however, you want to have a getter for something that is not a service. That’s where the second API comes in. You can pass in a lambda function that will be called when the value is needed for the first time. From then on, the value is cached. Some old code may look something like this:

this.__defineGetter__("_db", function() {
  delete this._db;
  return this._db = Components.classes["@mozilla.org/browser/nav-history-service;1"].
                    getService(Components.interfaces.nsPIPlacesDatabase).
                    DBConnection;
});


With the new API, that code turns into this:

XPCOMUtils.defineLazyGetter(this, "_db", function() {
  return Components.classes["@mozilla.org/browser/nav-history-service;1"].
         getService(Components.interfaces.nsPIPlacesDatabase).
         DBConnection;
});


Again, much nicer looking! If you are interested, the implementation of these methods can be found here.

Categories
Mozilla

New API Added on NetUtil

Did you know about the handy NetUtil object available when you import NetUtil.jsm? I bet you didn’t since it’s fairly new! There’s no MDC page yet, but the API is getting even better. Bug 508902 added a new method on NetUtil to create nsIURI objects. NetUtil will cache the IO Service so the calling site doesn’t have to. As more code starts to use this, fewer objects will have to cache the IO Service themselves.

The API mirrors nsIOService‘s newURI method with one minor improvement; the last two arguments are optional. Most callers in JavaScript tend to pass null for those last two arguments anyway, but when using NetUtil.newURI, they just have to pass the spec which should be easier.

New JavaScript code that needs to create nsIURI objects should start using this method.

Categories
Mozilla

Swing and a Miss

When we landed the asynchronous location bar, some people started to see substantially slower results. This was alarming since it was supposed to end up speeding or staying the same for everyone. After some investigation, we realized that the AutoComplete code was doing something very dumb with asynchronous searches. The problem was that the code would not actually handle the user pressing the enter key until the next set of results came in. Not only did this result in slower processing of the user’s selection, it also meant that weird race conditions would come up such as up opening a new tab, pasting a url in, press enter, and then switch tabs resulting in the reloading of the page that was just switched to. In other words, epic fail all around.

Luckily, the fix was trivial. Now we handle the enter keypress immediately when the user hits it, and not later. Problem solved :)