Johnathan Nightingale - Behind Mozilla Firefox

Mozilla corporation has a big share in changing the way we look at Internet! Of course, the Team Mozilla is full of magicians who bring you the safe, secure and the fast browser - Firefox!

We are extremely proud to have Johnathan Nightingale of Mozilla Corporation, USA on CE!. Johnathan answered questions asked by CEans from all over the world in our Small Talk. Check out our exclusive Small Talk with Johnathan -


CEan - The Big K: Hi Johnathan, please tell us about your job at Mozilla.

Johnathan: My business cards say “Human Shield.” Shield, because I work on Firefox’s security UI. Human, because I come from a human factors/usability background, and an important part of my job is making the interface easier for people to understand, making it something people find genuinely useful when interacting with sites online.

CEan - The Big K: How does it feel like to work on a product used by millions of users across the world?

Johnathan: I recommend it! Obviously it’s great to imagine that your work is reaching 150 million people, but honestly, the biggest thing I feel is responsibility. To our users, to the open, accessible internet, and to the people who have a lot invested in Mozilla’s success.

CEan - Archana: What according to you is the USP of Firefox & why?

Johnathan: Firefox is about personalizing, about making it your own. We make a browser that is chock full of awesome from the moment you install it, but it’s when you combine Firefox with the add-on community that things really start cooking. You know your own browsing better than anyone - add-ons let you build your own browser without writing code, and they let developers try out cool new ideas before they’re ready for mainstream integration into the browser.

If you’re not into add-ons yet, get yourself over to #-Link-Snipped-# and have a look around.

CEan - Elisa: What makes Firefox more secure than its competitors?

Johnathan: Security comes down to the question of how often our users are put at risk. There are a lot of things we do to keep that exposure to a minimum. There are straightforward code-level approaches: static analysis, moving functionality into managed code where possible, things of that nature. We supplement those by developing our own tools, things like Jesse Ruderman’s jsfunfuzz[1], which we share with other browser vendors to ensure that their users are protected as well.

The best defense we have, though, is people. We work to be responsive to security researchers that bring problems to our attention. A lot of researchers publish exploits publicly because they feel there’s no alternative, they worry that software developers will ignore them or try to bury their work. By demonstrating with immediate action that we take these reports seriously, Mozilla develops positive relationships with these researchers.

One of our biggest unnoticed security features is session store. When you shut down Firefox, you can tell it to remember your tabs, and re-open everything where you left off. The confidence that things will come back up where they were is what helps people click “OK” when we inform them that there’s a new security update available. We’re now at the point where we have over 90% of users on updated code within 6 days of release.[2] Helping people stay up to date without hassling them is what keeps them safest, in the end.

[1] Jesse Ruderman » Introducing jsfunfuzz
[2] #-Link-Snipped-#

CEan - Jerry: Firefox does not freeze as much as IE does…what is the secret?

Johnathan: We keep a very tight eye on performance and it’s been one of the big pushes again with the upcoming release of Firefox 3. I encourage readers to give the Firefox 3 betas a spin if they haven’t already; the improved performance even compared to Firefox 2 is impressive.

CEan - Kidakaka: Could you tell us more about the development challenges of the Mozilla engine considering the fact that it is one of the major open source initiatives? I am hinting towards the versioning and source control of the entire project, to be more specific.

Johnathan: I appreciate the angle of the question, but really the biggest challenge isn’t our choice of VCSM system, it’s the knowability of the code base in general. For a new developer it can be very difficult to know where to begin. The add-on infrastructure helps here too, since it gives people the ability to experiment in a smaller space - altering the UI without having to manage our build system. My advice there is to brace yourself for it, and ask questions early. Find an IRC client, get thee to irc.mozilla.org and get your feet wet.

As for source control, you’re absolutely right that CVS slows us downpresents certain challenges. Our trunk is very active, dozens of checkins a day is not unusual, and that means that patch management and merging takes up more of our time than it should. It is also a reasonably unfriendly environment for having small teams work on a shared-but-detached trunk collaboratively. So yes, we are slowly moving ourselves from CVS to Mercurial after a long debate, the traces of which are available for those who are interestedas we speak, though it’s a gradual transition; CVS will still be the source control of record for Firefox 3.

CEan - Kidakaka: How best would you describe the Mozilla development life cycle? It surely cannot be the waterfall model…agile maybe.

Johnathan: We have a model?

Before I worked for Mozilla, I worked in IBM’s software group. IBM was very conscious not to get trapped in old paradigms, and we had a lot of people come in to tell us about agility. , but aAt no time while I was there, though, did I see a process simultaneously as robust and as fluid as what the Mozilla community has developed.

Tactically speaking, all code gets reviewed before check-in, which is a basic, but important quality bar to set. We are very test-infected as well, much more than in most traditional shops I’ve seen. And we run constant performance benchmarks against the current code base, to catch regressions early. Doing things like these out in the open is great for code hygiene.

Strategically too, we try to resist the typical waterfall lock-in that occurs when initial release goals conflict with current realities. Driving a release at Mozilla is an extremely involved process of continuing triage and re-assessment. We have clear goals for each release, but try to maintain a broad window for cool as well, for individual developers scratching a fortuitous and low-code-risk itch.

CEan - Kidakaka: Could you give us more technical insights into why does Mozilla treat DOM as it does? e.g. - to get a certain item in IE, I can simply do a dom.<name>.<attribute> ... in FF, I have to do a Document.getElementById(<element's id>😉.<attribute> ... I have seen many a web developer getting befuddled by this difference.

Johnathan: Building Mozilla is always a balancing act between making things easier for web developers in the short term, and focusing on standards compliance, to make things easier for everyone in the long term. Sometimes we try to do a little of both, like our treatment of document.all, which is to work, but log a warning in the console. document.getElementById() can seem like a pain, but it’s much more reliable across platforms. Using the standards-based way of doing things also makes it more likely that your web app will benefit from targeted performance improvements we make to certain javascript functions that we know are popular with web developers.

Of course, my own solution when I need to do a lot of DOM traversal on the web is to just use jQuery.

CEan -Kidakaka: How do you differentiate between major releases of Firefox? As in, what defines that a version is 2.0.0.7 and 3.0?

Johnathan: Like most software projects out there our version numbers are, first and foremost, a way to tell our user and development communities what magnitude of change to expect. Changing from 1.0 to 2.0 is a big jump, and means functionality changes and potentially breaking changes to things like our extension APIs. With Firefox 2, we gave ourselves a lot of breathing room in our numbering scheme, with security and stability fixes being numbered in the fourth position (2.0.0.3, 2.0.0.4, &c.) to allow for various degrees of functionality change and API change over its lifetime. In hindsight though, it mostly just served to make our version numbers unwieldy, and for Firefox 3, I think we’ve settled on three digits instead of four, so that security fixes will be numbered 3.0.1, 3.0.2, and so on.

CEan - Crook: Why does FF2 eat twice as much memory as IE7?

Johnathan: This is actually a really exciting question right now, particularly for a technical audience like the people at CE. A lot of people have been working on this in Firefox 3, but no one’s worked harder than Stuart Parmenter, who really helped crack it open. It comes down to an issue with the way we allocate memory. In Firefox 3, we’ve already made several changes to improve things here, with more on the way. We are looking at moving some heap-based allocations to stack-based, to using task-specific memory arenas for certain big offenders (e.g. javascript string allocations) and as I write this, our source tree is closed so that we can test-land a new allocator to replace the C-standard malloc.

For a lot more information about this work, you should check out Stuart’s blog posts. The introductory one is here: #-Link-Snipped-# but there have been several follow-ups as well.

CEan - Kidakaka: What is with the names of all the browsers? Gran Paradiso ... we know that they are names of actual places, but ... some more information would be appreciated for all our CE + FF buffs.

Johnathan: Bon Echo, Gran Paradiso - they’re parks! Mozilla is a commons, so parks are a pretty natural fit, but it’s also just a rich source of really lovely names. Gran Paradiso is the highest peak in the Graian Alps, as I understand it, and looks like a lovely place, but I’m afraid I’ve never been.

Our nightly and trunk builds are all branded “Minefield”, to make it really clear what you can expect, if you proceed against all caution to the contrary.
CEan - The Big K: We thank you for taking out time to talk to us. What is your message to all Crazy Engineers?

Johnathan: Get better at failing. Trying and failing is a wonderful teaching tool, as an individual, as a company, as a worldwide software movement. Don’t make failing your aim, obviously, but don’t let fear stop you from trying 10 crazy ideas. The one success will pay for the 9 failures, and beats the heck out of just doing one safe, mediocre thing.
________________________________________
CrazyEngineers is thankful to Mitchell Baker & Melissa Shapiro of Mozilla Corporation for their help & support in making this small talk possible.