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.

My wife teaches high school physics. She loves putting quotes from famous physicists, mathematicians, and inventors on the wall of her classroom. After the death of Neil Armstrong, there was a lot of media coverage and I discovered a great quote from a speech that he made to the National Press Club in 2000:

“I am, and ever will be, a white-socks, pocket-protector, nerdy engineer, born under the second law of thermodynamics, steeped in steam tables, in love with free-body diagrams, transformed by Laplace and propelled by compressible flow.”

Because I thought my wife would really like this, I decided to make a poster of this quote on top of a picture of Mr. Armstrong walking on the moon. I created the design on zazzle.com and purchased it. Today I got the following response from Zazzle:

ORDER CANCELLATION NOTICE – Please modify your design(s) and re-order.

Hello Benjamin Smedberg,

Thank you for your recent order: XXXX

Unfortunately, we are unable to process your order due to a conflict with one or more of our acceptable content guidelines.

As a result, the following item(s) cannot be produced:

Title: Apollo 11 Neil Armstrong.jpg, I am, and ever wi…
Product Link: XXXX
Result: Not Approved
Content Notes:

• Design contains text or image that is in violation of an individual’s rights of celebrity/publicity. If you are interested in purchasing Official Licensed Merchandise from Zazzle please visit: www.zazzle.com/brands
• Design contains an image or text that may be subject to copyright. If you are interested in purchasing Official Licensed Merchandise from Zazzle please visit: www.zazzle.com/brands
• Your design contains an image or text that may be trademarked. This may be due to the actual design of the product, description or search tags that are associated to your product. Please feel free to submit a new design to our Marketplace from original elements

I suppose that the speech itself could be subject to copyright, but given the size of the excerpt and the occasion I don’t see how it is really relevant. The photo, being a product of NASA, is not subject to copyright. And I don’t see how right of celebrity or trademark could possibly apply to this at all.

Come on Zazzle, stop being stupid.

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!