browser.js is probably the most important file in the Firefox front-end, since it contains most of the JS code used by the main browser window. It’s also one of the biggest, at ~7500 lines. It’s a bit of a dumping ground, since it’s the most obvious place for main-window-scoped JS code to live, and there’s a lot of unrelated code spread throughout the file.
The idea of cleaning it up has been brought up several times in the past. We have made some changes that help – Services.jsm landed recently and helps reduce some of the XPCOM boilerplate overhead (though there’s a bunch of it left!), and Dão, Mano, and others have done some good work with piecemeal cleanup of cruft in various areas. It remains a gigantic file, though, and I’d like to try taking some bigger steps towards improving maintainability and approachability. I suspect those words could mean different things to different people, though, so I’m looking for some feedback or ideas about what exactly should be done. Here what I was thinking:
Split it up into multiple files
Splitting the code into several separate files and combining them at build time could help make things more organized. The idea would be to group pieces of code that are related to each other or that share the same purpose. We already do this for for some of the places code, for example. I’m not sure how much of a benefit we could get out of extending this technique, though, since there are a lot of small unrelated pieces, and hundreds of small scattered files could certainly end up sucking more than one humongous file. Getting the right balance might be tricky.
Move “static” methods to a common JS module
Some code in the file is general enough that it doesn’t need to be loaded for each browser window, and some pieces of code can be re-factored to make this possible. This would have the additional benefit of reducing the amount of JS that needs to be loaded/parsed for subsequent window opens, since JS modules are shared globally and only loaded once.
Just delete stuff!
The most obvious way to make browser.js more manageable is to just outright remove code! We’re always on the lookout for dead code, but I’m sure there’s a bunch of dead(ish) code still present that’s ripe for removal. There’s also not-so-dead code that we need to take a very hard look at. Going down that path can certainly be controversial, but we have bugs filed for several such ideas already, and I think it’s a path we need to explore further.
Have any other ideas? Let me know in the comments, or even better, file a bug and mark it blocking bug 448669!
Can we use a code coverage pass to identify largely dead code?
So my problem with splitting it up into multiple files and combining at build time is that error messages get junk line numbers (unless bug 246286 were fixed). Could we just include them all in browser.xul separately, does the fastload cache still mean we lose perf there?
Since we already include multiple files in browser.js at build time, it doesn’t seem like adding more would make the line number situation any worse…
My point was that we should stop doing this if possible.