This weekend bug 758812 landed on mozilla-central. So begins a long, slow process of splitting up browser.js into smaller pieces.
“What’s the deal with browser.js, anyway?”
It’s big. Too damn big. For those unfamiliar with it, browser.js basically contains a bunch of the code for driving the UI in a Firefox window. Anything you click or see changing as you browse probably involves this code. A browser needs to do a surprising amount of stuff to work, and over time browser.js has become an eclectic collection of code. About 13K lines of code, in fact. That’s a lot, and leads to a number of problems… It’s a daunting behemoth for those new to the Mozilla code base. It’s haphazardly organized (at best), so it’s hard to find things unless you already know what you’re looking for. And looking at Mercurial’s history for the whole file doesn’t really give you a clear picture of how specific pieces evolve.
“So what are you going to do about it, punk?”
Break it up! The first step landed, which is just spinning out a few big chunks of related code into #included files (about 2K lines). As time goes on (and we see how changes work out), we’ll likely spin out even more. Some of these pieces may also end up evolving into JSMs, which has modest benefits for improving memory usage and startup time. We might even be able to share some of this code across products (Firefox, Fennec, B2G).
“And the bad news?”
Well, there really isn’t any. If you’re a Firefox user, you won’t see anything change. If you’re an add-on developer, you’re unlikely to be affected by these changes. The cleaving of browser.js is currently just a source-tree change with #includes, so the resulting browser.js that ships in Firefox is mostly the same. Future changes to move code into JSMs will have some impact, but we’ll try to keep change small and approachable. Really, it’s only Firefox front-end developers who are likely to notice the changes, patches to certain code in browser.js may now need to patch code in browser-foo.js instead.
“I’m not seeing any cats in this post so far.”
I am never one to disappoint. Here is my cat wearing a tiara.
Dolske's blog 
I can’t speak to startup time, but splitting browser.js into multiple JSMs would create more compartments, right? I’d expect that would *increase* memory usage&em;indeed, the fact that compartment-per-global was a ~15% memory regression was due precisely to the fact that we added more (primarily system) compartments.
I don’t mean to discourage this work — we should fix this memory regression regardless of what you do in browser.js — but you should at least be aware of the memory implications for the moment.
It’s a tradeoff — overhead of a compartment vs each browser window having its own copy of the code+vars. I’d also like to think that by the time we get around to JSMifying this code, the compartment overhead will be even smaller.
Another point in favor of JSMs: code that isn’t used during a session might not need to be loaded at all. (Customize Toolbars, web developer stuff, download manager?)
Jesse: exactly.
Also, I suspect that in the long run compartments will be even more useful for watching memory usage and garbage generation. It’s hard to tune things or make comparisons if it’s all lumped together.
We really should gather some telemetry on this, but my guess is that the vast majority of browsing sessions are single-window.
Anyway, if this work encourages those who can to fix the CPG memory regression (bug 759585), then I’m happy!
Thanks for the cat!
tl;dr but nice cat!
Judging by the warnings in my JS console, it looks like browser.js is loaded twice even if you only have one browser window!
During the split up process has there been any talk of implementing lint tool for firefox js code? Of the few reviews I’ve had it seems a good portion of it were spent on nits about style. In the project I work on, pdf.js, we have been using gjslint with our bot on every pull request. From this I’ve seen:
– More consistent code.
– No time wasted being a human linter.
– A bot/lint tool complaining about your style feels less personal.