A key part of Mozilla and the Firefox product is that it was built by a huge team of volunteers. As Mozilla has hired more full-time engineers, we haven’t necessarily grown our volunteer hacker community to match. In order to build our volunteer community even more, I am now hiring a full-time community manager for Firefox engineering.

I am very excited about the opportunity to have a person whose sole job is dedicated to understanding, growing, and nurturing the Firefox developer community. For a while we’ve had a great “Coding Contribute” team who have been creating dashboards and tools in their spare time, and individually welcoming new contributors. This position will expand on that team and make it more effective. There are many things we don’t understand about our volunteer community, and it will be awesome to have somebody who can spend their time understanding volunteer motivations, skills, limitations, joys, and frustrations. The community manager will be an essential resource for module owners, managers, and other team members to understand how to bring in and guide volunteers and how volunteers can help meet Mozilla’s goals.

Anyone who is interested can view the job description and start the application process here. I would like to especially encourage current members of the volunteer community to apply, if this is something that you are passionate about and are interested in a full-time job with Mozilla. If you aren’t sure and you’d like to talk to me about it before applying, please feel free to contact me.

I was working on a project today and was seeing weird sort behavior and couldn’t figure out what was going on for a while. I finally discovered that JavaScript Array.map wasn’t returning the values I expected. In particular:

> "11.4.402.265".split('.').map(parseInt)
[11, NaN, NaN, 2]

I was a little worried that Mozilla was broken, so I asked the JS experts in IRC and got this interesting diagnosis from Jeff Walden (Waldo):

parseInt takes a second parameter that’s a radix; map calls its function with (value, index, thisArray)

This magic behavior of Array.map can be useful if you want to do even-odd behavior or other tasks, but it happened to be my personal footgun today. Be careful! My code now interposes its own function:

a.split('.').map(function(i) { return parseInt(i); });

I’m not sure I really want to know why parseInt(11, 0) returns 11.

Today, Mozilla Research publicly announced the Shumway project. Shumway is JS/HTML library which displays SWF (Flash) content entirely using open web technologies.

Live demo below: Click the car and then use the arrow keys to drive.

I am very excited about this project. There is a lot of Flash content on the web, and Flash is not available for many mobile users, including most new users of Firefox for Android and Firefox OS. Many popular sites are already converting to HTML content, but there is always going to be a long tail of Flash content which is not actively maintained. Although it’s still a research project, my hope is that Shumway will some day be able to play enough Flash content that we could include it as part of Firefox on mobile platforms.

Another possibility of the Shumway technology is that website authors could use Shumway as a JavaScript library to display their legacy Flash content in any modern browser. For example the Shumway team already has an online example of SWF content running in the browser without any browser support at all. This example works in Chrome, and we can probably make it even easier to automatically convert <embed> nodes using shumway with a little bit of scripting. (The example doesn’t work in IE 9 because IE 9 doesn’t support JavaScript typed arrays or “const”. Maybe future versions of IE will join the modern era.)

Mozilla is actively looking for volunteers who are interested in helping build out Shumway to its full potential. We need help implementing important builtin objects, testing and tuning performance, and building out a test suite. For more information, clone the github project, check out the wiki, join the mailing list, and join us on irc.mozilla.org #shumway.

I absolutely love this TED talk by Julian Treasure about how sound affects people. I was especially struck by his discussion of how design/architecture can greatly affect academic success by changing the soundscape in a classroom.

Personally I am very sensitive to noise. It’s exhausting to spend time in places which have even low levels of background noise, and loud events such as amplified concerts or sporting events are often physically overwhelming. Even the Mozilla offices, with their open floor plan, are frequently distracting and make it hard to do concentrated work.

Gregory Szorc has an interesting post about the execution time of Mozilla makefiles. In it he describes the mechanism that pymake uses to parse a makefile into an AST, and then evaluate the makefile in a specific context. His data shows that the majority of time spent in pymake occurs during the evaluation phase. This is correct, but this slowness is partly a consequence of how GNU make parses and evaluates variables. I believe that it would not be hard to trade minor incompatibility with GNU make and achieve significant speedup in pymake execution.

When GNU make encounters a “normal” recursively-expanded variable, it does not perform any sort of parsing, it merely stores the text. This means that it is possible to invalid syntax into a variable, or to build up a function from multiple appending assignment, for example:

VALUE = aabbcc

TESTVAR = $(subst a,b,
TESTVAR += $(VALUE)
TESTVAR += )

default:
	@echo $(TESTVAR)

The GNU make output of this testcase is “bbbbcc”. Early versions of pymake instead threw a warning about an unterminated variable assignment and the result was ” aabbcc )”.

Building up a makefile variable dynamically may be useful in some special cases, but this is not a technique that most projects use. It does mean that pymake cannot parse variables at the time they are assigned: instead it must wait until the variable is evaluated. (This behavior is in the pymake testsuite).

Variable expansion is by far the most expensive part of core pymake execution. The current parsing method which uses python regular expression engine is relatively slow. Other methods we have tried including hand-parsing using string indexes and were even slower. Parsing all of the config.mk and rules.mk variables as part of the cached AST would significantly improve pymake runtime speed on the Mozilla tree, because we could parse each variable once, instead of re-parsing them at each execution.

The original development versions of pymake did do early parsing, and I only changed it to do parsing at evalation-time when the gmake incompatibility was discovered. I don’t think it would be too hard to switch back. I encourage somebody to try it.

I was recently asked to provide a list of all the plugin-related changes from Firefox 11 to 12 to 13. This is actually not the easiest question to answer: both bugzilla and source code searches may produce false negatives and false positives.

Using bugzilla to answer this kind of query fails whenever the bugzilla metadata is incorrect or misleading. Usually the Target Milestone for a fixed bug indicates the release version that it first ships in, but it is not uncommon to forget to set the TM for bugs. And when a bug is backported to an earlier train, the target milestone doesn’t always get moved backwards to match. In addition, filtering by bugzilla component often leaves out important bugs, since changes to graphics, DOM, layout, or JS can make noticeable changes in plugin code.

Instead, I decided to use Mercurial to answer this question. Almost all changes which affect plugin function are going to be located in the following directories and files:

• dom/plugins
• content/base/src/nsObjectLoadingContent.{h,cpp}

So what I really wanted was a list of changes between two Firefox releases which touch that set of files. But how can I use Mercurial to search only the revisions between two specific releases? Here is the branch diagram for the Firefox trains:

By default, hg log -rfoo:bar will list the changes between two particular revisions in whatever linear order these revisions happened to be pulled into your repository. This means that you may get different results depending on the order you pulled. But there is a feature in Mercurial called “revsets” that lets you pick changes in much more specific ways. For more information about revsets, issue hg help revsets or see the online documentation.

In this case, I wanted to log all the revisions between the mozilla-central branch point of Firefox 12 and the release of Firefox 13. Revsets can figure the branch point with the ancestor operator, and can then list all the changesets between two revisions (including all branch/merge revisions) with the :: operator. So the final command for finding all changes which touch plugin files between Firefox 12 and 13 was:

$ hg log -r "ancestor(FIREFOX_12_0_RELEASE,FIREFOX_13_0_RELEASE)::FIREFOX_13_0_RELEASE" dom/plugins/ content/base/src/nsObjectLoadingContent.{h,cpp}

Special thanks to Dirkjan Ochtman (djc) for introducing me to revsets!

After Firefox 4, the Mozilla community decided that we needed to be more agile and ship Firefox faster. This “rapid release” process has been absolutely fanstastic for the Mozilla engineering/development community: we have been able to develop more quickly, and the process has made Firefox development a lot less stressful because there will always be another release in 6 weeks. But rapid release has its downsides, and I think we, as a community, should consider whether we are serving the needs of our users.

Much has been said about how the rapid release process is problematic for “enterprise” users, or other situations which use managed deployments and have unusual testing requirements. I know that we are discussing a plan to work with enterprises to provide a longer-term support system for these users.

But even for ordinary “consumer” users, there is still a significant pain point in the rapid release process. Not all extensions are keeping up with rapid release. Traditional Firefox addons are given almost infinite power to modify the application, but with this power comes a price: any change we make has the possibility of breaking an addon.

We are working on many projects to mitigate this problem. The Add-on SDK (Jetpack) gives addon authors a way to write addons against a stable API that we promise will be maintained across versions. And most of the time, even though an extension is actually compatible with a new version, we aren’t sure about this compatibility. We are planning on asking our Aurora/Beta testing audience to help us test addons to mark them compatible by default.

But even with all these mitigation strategies, there are still going to be users who have incompatible addons on each 6-week cycle, either because they are using unusual or custom addons, or because an addon which is critical to that user needs major update work which cannot be completed in a particular release cycle. Users are then given the unfortunate choice of updating Firefox and having important extensions broken, or not updating Firefox and potentially being exposed to security flaws.

We should continue the existing rapid release process: it makes our development practices better, and for a majority of users it gets them the newest and best web features and Firefox performance improvements as quickly as possible. But for users who have a long tail of addons which are updated less frequently, we should complement the rapid release vehicle with a stable release which will contain security fixes but won’t break extensions for a longer period of time. This could be a release vehicle which has updates only on a 6-12 month cadence.

This is definitely not an easy decision; maintaining a stable version will cause pain for our community. The development community will have to do security/stability backports against older code. Our testing community will somehow have to deal with an additional train of releases beyond the existing nightly, aurora, and beta release trains. We will have to deal with pressure to rush a feature into an stable release, or delay the schedule in order to pick up an important feature. Finally, a stable release will be a pain for extension authors themselves, because extensions must provide and maintain versions which are compatible with both the rapid and stable releases.

I fear that we are frustrating our users with extensions, which ought to be one of Firefox’s greatest strengths.

As Mozilla increasingly focused on being the best browser for mobile devices, we will need to focus on battery usage. This is already an issue on laptops, where some browser activities like playing movies can chew through battery very quickly, but it is even more an issue on smaller phone and tablet devices where batteries are smaller and users expect at least a full day of battery life.

The first part of this project will be accurately measuring our power usage under various conditions. As with any software engineering project, you are what you measure! To that end, Mozilla is looking for both volunteers and potential paid employees who are experienced at measuring and tuning power usage on small devices. If you have experience with software or hardware tools for measuring power usage (both is even better), please contact me at benjamin@smedbergs.us, or go ahead and apply for the job.

Mozilla is a great place to work, whether you are working out of one of our offices (Mountain View, San Francisco, Toronto, Paris, London, or Auckland) or working remotely. Especially with a new project such as this one there will be plenty of opportunities to chart your own course, and improve software which is shipped to millions of users.

The system is working. We found a crash bug soon after it was introduced, and saved Firefox users pain and aggravation.

Yesterday, dbaron was looking through data from crash-stats.mozilla.com and found a spike in crashes on nightly builds. Because this was a bug related to delivering stream data to plugins, an area that I rewrote for Firefox 4, dbaron cc’ed me as he filed bug 646839.

The bug immediately triggered alarm bells for me: all of the crash stacks were taking “unusual” paths having to do with multipart streams, or networking code that was being intercepted by JavaScript, probably from an extension. In addition, nothing had changed in the Mozilla code that looked remotely related to the crash. After some data mining, I discovered that the users who were crashing had a beta version of Adblock Plus installed. I immediately cc’ed Wladimir Palant, the ABP maintainer.

It turns out that a new feature in Adblock Plus was eating some error codes, leaving our plugin code in a bad state. This resulted in crashes. And the new version of Adblock Plus was schedule for release to Firefox release users soon! Because of dbaron’s quick discovery, a nightly user base who runs beta versions of extensions, and quick thinking all around, we were able to avert a problem for users of Firefox release builds.

This kind of success story is possible because of many tools and systems which interact, but it is mostly possible because Firefox development is an open community where everyone works together and we don’t hide our flaws. And that’s why I love working on Firefox.

Are you interested in becoming a volunteer contributor to Mozilla? See our contribution center for more information about how you can help with coding, QA, documentation, support, localization, marketing, or other efforts of the Mozilla community. Or do you have the skills and experience to be a Mozilla employee? Contact me, or visit the Mozilla careers site and apply today!

In Firefox 4, tab are “on top” by default. When you are in maximized mode, this also means that the tabs move up into the titlebar. I understand that the UI design team decided to do this to make the tabs easier to click (because of Fitts’ law), but I personally find this behavior annoying, because it means that you cannot use the title bar for its normal tasks. I almost always double-click the titlebar to switch between maximized and regular mode, or drag the window to the side to get half-screen mode.

Fortunately, there is a hidden preference which controls this behavior. You can restore normal title bar behavior in two ways:

• Set the hidden preference “browser.tabs.drawInTitlebar” to false, using about:config
• Install my extension Aero Window Title, which not only changes the default preference for you, but also puts the window title back onto the screen so that you can see the title of the current tab easily.

While I’m talking about it, I’d also like to plug my other new extension, Iconic Firefox Menu, which will turn the orange Firefox menu (on Windows) into a Firefox icon. Together, the two extensions look like this: