24.2.0, at last, released, and Mozilla tries to get rid of extra hair

Thanks to everyone who commented on our last post about targets for the next "major release" of TenFourFox. The overwhelming consensus is that, although there is some trepidation (and well-deserved, apparently) over Australis, it's the future of Firefox like it or not, and if it's technically possible people would rather continue to evolve and try to maintain source parity rather than fork.

So we'll try. 26 is still in pieces and there will probably not be an unstable release, just a set of changesets for the perverse interested. However, I am pretty certain 26 will work. After that, my thinking is to jump to either 28 or 29, since if Australis doesn't gel, there's no point in expending additional effort. I'll have some time over the holidays to deal with this since I'll be between terms in my Master's degree program.

Meanwhile, 24.2.0 is out. This includes the performance tweaks I discussed (issues 253 and 254); release notes and downloads available at the usual places. This will be the first official release of 24 to the general public, so let's make it a good one. Assuming no obvious issues, 24.2.0 becomes live Monday night Pacific time as usual and we will wave good-bye to TenFourFox 17. You'll also get to see our new Mavericks-inspired Apple swipe, as is my custom. :)

The newest technical concern is Mozilla's renewed push towards Electrolysis, or multi-process Firefox. Most of you are familiar with Chrome's use of a process per (sometimes several) tabs, although Internet Explorer 8 actually pioneered this approach some months before. The issue Electrolysis specifically addresses is unique to Firefox: most of the browser is written in JavaScript, but because all JavaScript runs on the main thread which also services user requests (including from web pages, because accesses to the document are not thread-safe), when a page's script stalls, it also stalls any browser code that is waiting to run, and the entire application must wait for the script to run or be cancelled. Using a JIT to compile JavaScript only reduces this latency; it does not eliminate it. Compared to this problem, improving browser stability and security is actually a remarkably secondary issue, though separate processes also achieve that too.

Running webpage scripts in a separate execution context is not a new idea; Mozilla played with an idea called "supersnappy" which would have done this in single-process Firefox, but the plumbing required was very complex and delicate. Electrolysis itself has been around in various forms as far back as 2009, and modern Firefox Android and Firefox OS use it, but the desktop browser does not due to lots of things that don't work. Even now, the browser is only up to the point where basic browsing works; many add-ons won't work at all. (Don't try to enable this on TenFourFox, by the way. If it starts at all, it will likely crash very soon afterwards. I'll explain why in a moment.)

The first iteration will just have a single content process within which all the tabs run, which diminishes the memory overhead while still getting most of the stability benefits and some of the performance benefits. However, a lot of work must be done on add-on compatibility. Most Jetpack-based addons (like the QTE and the MTE) will work fine with Electrolysis Firefox, but older or more low-level addons (like OverbiteFF) may need modification. There are also lots of potential race conditions because you now have two queues of JavaScript which may deal with items in non-deterministic order. Since the browser interface is JavaScript too, they really need to get this right.

The amount of time required to get this plumbing in and fix all the outstanding bugs indicates that this will become mandatory at least after Firefox 31. That's good, because as written, it won't work with 10.4; we don't have the functions needed to spawn processes the way IPC Chromium expects (which handles multiprocess Firefox), and they are stubbed out with debugging messages in the current version of TenFourFox since it doesn't need them. The underlying work to fix this is issue 66. Even then we may have IPC bugs in 10.4 getting the processes to talk to each other, although I believe Electrolysis is achievable on Tiger overall and will be beneficial to us too ultimately. Fortunately, we don't have to worry about it yet.

Back to work on TenFourFox 26, after I finish this paper. *sigh*