I completed some reviews, including some for relatively exciting patches from Dão:

• Turning on and fixing the position of the “Firefox” menu button on Windows Vista/7
• Making tabs-on-top the default on Windows (see Alex’s post for more details)

I also spent a bit of time reviewing fixes for dolske‘s prompting code rewrite that landed last week as well as cleaning up the new HUD panel‘s styling.

Next week, I plan on trying to wrap up as much of the notification-related stuff as possible, and move on to getting some patches up for the Account Manager work. Also need to do a bit of prep for the Summit which is coming up quickly!

Still rather ugly, but at least it’s functional!

Some things I’ll be looking into next:

• the dismissal behavior – currently dismissing the notification (i.e. clicking elsewhere on the screen) denies the geolocation request. I think we want to instead keep the request pending and allow you to access it later from the site-identity menu, but that requires some extra work (tracking shown/unshown notifications, etc.)
• make notifications triggered from background tabs/windows behave correctly (right now they’re just ignored)
• multiple-notification stacking
• support for different priorities (not sure this will be needed)
• styling! – Stephen is working on mockups for menu-buttons, which is probably the most obvious issue

The current working API is very similar to the existing notificationbox API. It’s definitely not set in stone. Right now it looks like this:

var mainAction = {
  label: "Share Location",
  accessKey: "S",
  callback: function() {
    request.allow();
  },
};

var secondaryActions = [
  {
    label: "Always Share",
    accessKey: "A",
    callback: function () {
      Services.perms.add(requestingURI, "geo", ALLOW_ACTION);
      request.allow();
    }
  },
  {
    label: "Never Share",
    accessKey: "N",
    callback: function () {
      Services.perms.add(requestingURI, "geo", DENY_ACTION);
      request.cancel();
    }
  }
];

var dismissalAction = {
  callback: function() {
    request.cancel();
  }
};

Notification.show("geolocation", "title", message,
                  "chrome://browser/skin/Geo.png",
                  mainAction, secondaryActions,
                  dismissalAction, browser);

That still needs some CSS tweaking, obviously (in general, and for the button specifically: bug 509642), and Neil’s work in bug 554937 should make showing the actual popup even easier.

I also did a few other things of note this week:

• worked on some search service changes to enable changes to the Google search plugin that should make the search experience better
• did a bit of experimenting with moving some browser.js code to a JS module – nothing real yet
• worked on a security bug
• did some code reviews

Usually the justification that fuels long debates about determining the One True Mozilla Code Style is that well-defined, strictly enforced, project-wide guidelines will help new contributors and make the code easier to maintain. Some people seem to also be suggesting that the guidelines be applied equally to all of Mozilla’s C++ and JavaScript code, since the two languages share much of their syntax. I don’t buy it.

I think that the benefits to a common style are often oversold. Consistency tends to be highly valued by us software developer types, sometimes to an unhealthy degree. I may find a particular bracing or indentation style unappealing when I approach new code, but I think it very rarely significantly impacts my ability to understand or contribute to it, assuming it’s at least internally consistent. I’m sympathetic to the idea that a common style can be beneficial at the file- (or maybe even module-) level, even if only for aesthetic reasons, but I think that trying to create and enforce more ambitious policies usually ends up being more trouble than it’s worth, especially for a project the size of Mozilla. The benefits to cross-module style guidelines just seem mostly theoretical to me, even more so for policies that attempt to span Mozilla’s loosely defined front-end/platform and JS/C++ boundaries.

Finding a single policy that covers all aspects of code style while satisfying even just a plurality of developers in a project this large can be costly just in terms of time spent debating. Add to that the time spent attempting to normalize the code base with large style-only cleanup patches, which would be necessary given our current state of affairs, and I think the scales are already tipped in favor of more tightly scoped code-style policies.

In practice, the project has settled into an fairly stable equilibrium already – we have a style guide, but the economics of making all of our code follow it, which would require both carefully auditing new code and fixing up old code, just haven’t worked out. I think we should stop kidding ourselves into thinking that they someday will, or that they should.

Accessing the tab context menu

One of bug 347930‘s changes was moving the tabbrowser context menu from the <tabbrowser>’s anonymous content to the tab container’s anonymous content. The tab container is also no longer a child of the tabbrowser, so some common methods of accessing the context menu <menupopup> element broke. I tried to address this in bug 554165 by making two changes:

1. Adding a gBrowser.mStrip compatibility shim JS object to keep some of the common references working
2. Introducing a gBrowser.tabContextMenu property as a supported tabbrowser API. The hope is that extensions will make use of this property rather than the hacky alternatives they’ve been required to use in the past. We can keep this property working regardless of the underlying implementation details, which could potentially change again in the future.

Adding elements to the tab context menu

MozillaZine community member “onemen” pointed out that putting the tab context menu in anonymous content made it a pain to modify (requires modifying it dynamically from code). So I filed and fixed bug 554991, the net effect of which is that the “tabContextMenu” <menupopup> is now defined in browser.xul, and can be modified using normal XUL overlays. It’s also still accessible via gBrowser.tabContextMenu, of course.

Both of these changes only apply to Firefox trunk builds, which means they don’t apply to 3.6 or earlier.

The idea of cleaning it up has been brought up several times in the past. We have made some changes that help – Services.jsm landed recently and helps reduce some of the XPCOM boilerplate overhead (though there’s a bunch of it left!), and Dão, Mano, and others have done some good work with piecemeal cleanup of cruft in various areas. It remains a gigantic file, though, and I’d like to try taking some bigger steps towards improving maintainability and approachability. I suspect those words could mean different things to different people, though, so I’m looking for some feedback or ideas about what exactly should be done. Here what I was thinking:

Split it up into multiple files

Splitting the code into several separate files and combining them at build time could help make things more organized. The idea would be to group pieces of code that are related to each other or that share the same purpose. We already do this for for some of the places code, for example. I’m not sure how much of a benefit we could get out of extending this technique, though, since there are a lot of small unrelated pieces, and hundreds of small scattered files could certainly end up sucking more than one humongous file. Getting the right balance might be tricky.

Move “static” methods to a common JS module

Some code in the file is general enough that it doesn’t need to be loaded for each browser window, and some pieces of code can be re-factored to make this possible. This would have the additional benefit of reducing the amount of JS that needs to be loaded/parsed for subsequent window opens, since JS modules are shared globally and only loaded once.

Just delete stuff!

The most obvious way to make browser.js more manageable is to just outright remove code! We’re always on the lookout for dead code, but I’m sure there’s a bunch of dead(ish) code still present that’s ripe for removal. There’s also not-so-dead code that we need to take a very hard look at. Going down that path can certainly be controversial, but we have bugs filed for several such ideas already, and I think it’s a path we need to explore further.

Have any other ideas?  Let me know in the comments, or even better, file a bug and mark it blocking bug 448669!

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 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.

In addition to being a fun project to work on code-wise, it also gave me the opportunity to work in a team that’s been rapidly growing. Since I got involved, a bunch of new contributors have joined in with contributions to the front-end: bcombee, stechz, vingtetun, fabrice, froystig and mwu, to name a few. Combined with the rest of the mobile team and the Mozilla project in general, the project’s in pretty good shape to kick butt in 2010 and beyond.

With the mobile team in good shape, and with Fennec 1.0 in the RC stage, I’m taking advantage of the new year to transition out of my focus on mobile and return my primary focus to “desktop-edition” Firefox. While I’ve had a great time on-loan to the mobile team, I’ve also missed working closely with the Firefox team on pieces of the product that got me involved with Mozilla in the first place, and I feel that I have some responsibilities that I haven’t been able to keep up with as much as I should while focusing entirely on Mobile.

So in the immediate future, I’m looking forward to contributing more actively to the Firefox team’s Q1 goals, but I’m not disappearing from mobile, either. I expect to continue doing some reviews for changes to the mobile code I know well and will generally help out where I can. I’m also still quite interested in eliminating many of the things that cause us to treat the projects as separate entities (on a code-level as well as organizationally). I think that ideally, having to choose between focusing on either “Fennec or Firefox” should make less sense as the two projects evolve and as mobile gets more established, and I’d like to work towards making that happen.

To that end, I’ll be writing up some of the lessons we’ve learned in mobile in the coming weeks, and talking about how to integrate those into Firefox.

So we’re going to combine forces to bring you the latest in status updates. (I will also shamelessly use this opportunity to bump my blog’s latest post into this year – welcome to 2009, readers!).

Here’s a teaser:

“We want Firefox to override [...] the user [...] bad news”

Check out Curtis’ update over on his blog to get the full scoop.