Gavin's blog

I’ve made some progress since my last post:

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);

Just recently I started working on implementing a new notification system for Firefox. It’s been discussed and blogged about before, and both Neil and MattN have worked on it before, so the task mostly involves just updating, cleaning up and completing their work. It’s being tracked by bug 398776, and I’m still in the early stages. Here’s what I threw together just so that I could test the API:

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

The topic of code style guidelines has come up again just recently in the newsgroups. This isn’t the first time, and probably won’t be the last. Everyone has an opinion – some strongly held – about where control statement braces should go (K&R baby!), how you should wrap multi-line conditions (logical operators at EOL!), and how many spaces (or tabs! ew!) should be used for indentation (2!).

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.