Monday, November 24, 2014

Electrolysis means splitsville

Mozilla continues their work towards multi-process Firefox ("Electrolysis" or e10s), and recently enabled it by default for nightly builds. It is still incredibly buggy and Mozilla is not porting the change forward to aurora or beta builds ... yet. However, it is probably the highest priority project at Mozilla and e10s as the default for release builds is going to happen sooner or later; I'm projecting early after Firefox 38, possibly as early as Firefox 39. Once this occurs, single-process Firefox will likely persist as a backup for one or two versions at most. When single-process no longer takes place even in safe mode, that's the end of the transition.

10.4 will not build Electrolysis without writing support for issue 66, and based on some code I've been reviewing, possibly not even then. There are lots of workarounds for threading problems in 10.6 which will almost certainly plague 10.4 and 10.5, quite probably other problems with the older operating systems, and then potential endian issues with serializing data over IPC. If Mozilla had gotten e10s working for Firefox 4 as originally planned, there was a good chance we could have made it work then since Mozilla still supported 10.5 and most of the code was still appropriately endian-agnostic, but they didn't, and we won't. 10.6 support is likely to end in the very near future as well, which dooms us further.

As a result, I'm declaring now that in its current state, Electrolysis will not be supported by TenFourFox. I don't think it can be done on our older OSes in a satisfactory fashion, let alone by one guy, so if and when Mozilla makes it mandatory that's where source parity will end. Assuming no breathtaking technical breakthrough on my part, if it appears to be imminent after the 38ESR diversion (which is my current estimate), we go to feature parity at the end of 38ESR.

Remember, feature parity does not mean the browser stops developing -- it just stops mirroring an official branch of Firefox. By 38 we will have the strongest suite of HTML5 and ECMA6 support available for OS X on PowerPC, including <picture> support and WOFF2 webfonts, and I'm still working on getting IonMonkey PowerPC complete as well as our MP3 playback module. Should I cut support there, I also intend to continue backporting relevant security and stability fixes to the extent they apply, as well as necessary updates to our encryption suite so that HTTP/2 and TLSv1.3 are fully supported. Suitably maintained, we should still have a top-tier layout engine for at least one to two years after the end of ESR38, and a functional one for some time after that. Watch this space.

The release of 31.3.0 got delayed to December 2, which is annoying, because I spent the weekend building it instead of watching the calendar. Fortunately, no patches relevant to us so far have landed afterward, so these already-built versions will be uploaded later this week assuming there are no last minute changes. Happy Thanksgiving.


  1. Thanks again for all your work. 31.2.0 has been a rock.

    The folks who work on Roccat have really hit a wall. They just came out with 4.6 update. 4.5 was horrible, taking minutes to load on my 1.67GHz Powerbook G4, which is one of the supposed fixes they have in 4.6. Performance overall has been rough with all the 4.x releases. At least for me. If it were not for you I'd have to go with INTEL Inside. Well, there is WebKit, which crashes for me at times, the little I use it.

    Happy Thanksgiving.

    1. Would you mind sending me the crash reports of the crashes you get with WebKit?

      I'm maintaining WebKit primarily for myself and I find it's really stable for what I do with it (I'm using it for all web browsing I do at home) - and the most frequent crash I had in the past few months (and some others) should be fixed in 537.78.2_2.

      There are some known Safari crashes that don't seem to have anything to do with WebKit directly - I can't fix those unfortunately. If you'd send me the crash reports (~/Library/Logs/CrashReporter/Safari*.crash) I could tell you if your crashes are of that class, which I can't fix.

    2. Where should I send the crash report to you.

    3. At the Leopard WebKit project page you may add a message to issue 77 with the crash report(s) attached (

      I forgot to mention that in the case of using the WebKit application the crash reports should have been saved as "~/Library/Logs/CrashReporter/WebKit*.crash".

      (By "WebKit" you have meant WebKit from the "Leopard WebKit" project, didn't you?)

  2. This comment has been removed by the author.

  3. I don't think the endian issues in e10s are that bad. I've been sometimes running with e10s enabled on my powerpc Linux builds from mozilla-central and things generally work. I find its slower than single-process mode and sometimes tabs stop responding but these might not even be endian or ppc specific issues.

    1. I hope you're right about the endian problems (though some of the int64 bugs I've fixed don't make me as confident), but we've still got the issues about 10.4 and 10.5 which have some well known threading problems we've run into before.

      Interesting that it's slower too, though always hard to judge on a very early release, of course.


Due to an increased frequency of spam, comments are now subject to moderation.