Gavin’s blog

I just landed the patch for bug 512784 on mozilla-central. It adds a new module to the toolkit whose sole purpose is to expose memoized getters for common XPCOM services on a simple “Services” JS object. The first pass involved adding getters for the prefs service, observer service, window mediator, permission manager, IO Service, prompt service, and search service. This patch also updates Firefox’s browser.js to make use of the module, which means that trunk-based extensions that run code in Firefox chrome windows can start making use of it if they’d like.

Here’s an example of one of the changes:

+// Services = object with smart getters for common XPCOM services
+Components.utils.import("resource://gre/modules/Services.jsm");

 function getTopWin()
 {
-  var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1']
-                                .getService(Components.interfaces.nsIWindowMediator);
-  return windowManager.getMostRecentWindow("navigator:browser");
+  return Services.wm.getMostRecentWindow("navigator:browser");
 }

I expect to add some other services to it as I look at expanding use of the module (Mossop has some suggestions in the bug). We might also add an equivalent in Firefox for browser-specific services, if that proves to be useful. The end goal is to remove a lot of the XPCOM boilerplate junk we see spread around our front-end JS code, and a side benefit is the reduction of unnecessary getService() calls for services that are already guaranteed to be otherwise instantiated and kept around for the app’s lifetime. This necessarily implies that JS scopes where the module was imported will now have permanent references to services after their first use, which is worth keeping in mind, both when making use of of the module and when adding additional getters to it.

I’m going to give weekly blog status updates a shot. I suspect planet already gets inundated with them near the end of the week, so maybe I’ll try adjusting my schedule by a few days. Or maybe I’ll end up just posting them on wikimo instead. Either way I’ll try to keep them interesting!

I didn’t think I was going to end up doing this, so I didn’t take detailed notes of everything I’ve done this week. I’m going to try to get better at that.

Accomplished this week:

• tried to keep the review queue cleanup rolling from last week, but I think I netted out even (or slightly negative). Current state: 33 pending requests.
• reviewed dolske‘s plugin crashing UI patches (bug 539848, bug 538910)
• helped test the 1.9.3 alpha 1 branding changes (bug 543564)
• wrote some additional tests for bug 512784 (consolidated smart getters for common services). ready to land once it gets rs=Mossop
• spent some time reviewing patch for bug 480350 (tab matches in awesomebar)
• wasted a bit of time arguing with RSnake on his blog

Up next (roughly in priority order):

• shorlander‘s going to be filing bugs for proposed theme/UX changes, will need to triage/prioritize those with dao
• need to make progress on browser.js cleanup/simplification – I want to get a list of actionable items by mid-next-week and get patching
• I have some mobile blog post ideas and notes that I really need to turn into posts
• try not to give up too much ground on review queue clearing
• want speak to Ryan about some changes required for bug 511017 (allow default search plugins to be updated, allowing them to get locale-specific search URLs to avoid redirects through google.com)
• would like to resolve bug 479334 (improved en-US spellcheck dictionary, including better merge scripts to ease taking changes from upstream hunspell and chromium). just needs a final test run and a couple of tweaks before landing, I think.

Ideally I think my “upcoming” tasks would be as granular and clearly defined as my “completed” tasks, I guess, but they’ll probably be easier to split out into specific tasks once some of the planning/exploratory work is done.