Big fat blog post: 14, 15, 10.0.6, Mozilla soul-searches, clouds on the horizon, another PPC trojan, unicorn rainbow farts, etc.

Wow, there's a lot going on lately. So let's get to it.

10.0.6 is still getting patches landed -- I wanted to build it earlier this week but Mozilla is still dropping security patches and it is doubtful there will be a build before Friday or Saturday. 14 will probably come out around the same time as no major issues have been identified so far. 10.0.6 and 14 will include issue 160, the JavaScript JIT latency tweak, and a stability enhancer found during the workup of issue 165, which strictly speaking was for an unrelated problem that affects 15. I will make a separate post for each when they are available. Lingering discoveries are that we have some event bubbling tweaks to make (issue 168) and a patch for methodjit-based JavaScript typed arrays (issue 167) which is being held for test failure on my local machine, quite likely a combination of different compiler and my own foibles, and to determine if it actually pays off. These will not land on 14 and probably not 15, but possibly 16.

I'm glad to have started on the port for 15 early because we not only had to solve issue 165 (which turned out to be a Mozilla bug and was pushed upstream as bug 771320), but also figure out a wallpaper fix for crashes on quit (issue 169), and I'm still working on pieceing the AltiVec WebM accelerator back together after libvpx was "upgraded" again (issue 166). I also intend to start publicizing the QuickTime Enabler to stable and unstable users as a standalone extension; I tried to integrate it in the browser but it just doesn't work right and it's probably because Jetpack was never really built for that. The debug version of 15 is running on my G5 and as soon as I have working architecture builds I will post changesets in progress. Because it is debug, it is hard to say if the large number of architectural changes in it really make any difference for performance, but I will say that I have made the executive decision to disable the built-in PDF viewer. It's just painfully slow, even on a quad, even on the Core i5 they make me use at work in the real Firefox 15 Aurora. pdf.js could have used a little more time in the oven.

And that brings us to the gossip portion of this article. Mozilla is gamely holding onto their market share despite the assault of the ravenous horde Chrome, but trying to out-Chrome Chrome has taken its toll and there is no small amount of soulsearching in Mountain View. A total of three posts this week from former Mozilla staff, one and two from Jono Xia and another from Atul Varma, provoked a lamentably predictable, somewhat defensive-sounding response which can probably be considered a tacit official Mozilla statement from Johnathan Nightingale, Firefox's senior director of engineering.

Jono makes the observation in his first post that, for all its flaws and the fact that Chrome will eat the universe and while laughing cacophonously ventilate its backside upon us for ever believing that Google was a benign and totally not evil corporation that would only ever use their browser for awesome, they made the crucial observation that the automatic update system had to be properly quiet and painless and fully formed from the very first day, even if the browser was not, because then you could serially update the browser using that fully formed quiet painless system as you made improvements and no one would notice. Moreover, in his second post, he also points out no one has noticed not merely because the updates were quiet but also because very little UI/UX code has in fact changed and the forthcoming 10.6-only Chrome 22 still looks and works an awful lot like Chrome 1. Mozilla did neither of these things, introducing upsetting changes from update to update, busting add-ons until "default to compatible" in 10, and requiring user interaction to actually install the update such as interrupting your current session, and it duly reaped the ire of its userbase for these sins. But the most important conclusion he draws is that other than the shining true believers, people don't use your software because they love it -- they use it because it works and p*sses them off less than the other available options.

Atul follows this up in his own post by pointing out that people really don't like to upgrade. (Well, duh. He must have been talking to our users!) Many people don't want to be on the bleeding edge; they want something that lets them do what they need to do and doesn't interrupt them doing it. Upgrading is not cost-less, even if the upgrade doesn't cost any actual dollars up front; the cost is time, possibly workflow, often adjustment, and sometimes creature comforts and extensions that don't work in the new paradigm.

I'd like to say that johnath-pro-Mozilla made a reasoned, cogent acknowledgement of these issues, but unfortunately I can't say he-pro-they even made a reasoned, cogent rejection of these issues. Instead, the post basically says, "we're not trying to out-Chrome Chrome, we love you, and those guys are wrong, so there." It doesn't acknowledge Atul's point except to say that "we don't upgrade bad now" and hardly addresses most of Jono's criticisms at all, let alone substantively answers them. Really, as rebuttals go, the response is notable for its wanting brevity even more than its lack of spirited debate.

I like to think that TenFourFox has addressed these issues as well as we can within the constraints of what Mozilla makes available. We use the ESR as our stable branch precisely because it eliminates churn -- people can be kept secure and made whole without upending them significantly other than a restart. After our period of wilderness wandering from 4 to 9 while we shook out the kinks, we're pretty stable on 10 and if all goes well, we will have another stable home on 17. For stable branch users, there will be no little surprises when you bring the browser up again and it will work pretty much like it worked before you updated, systems updates notwithstanding. If you want the new hotness, you go unstable, and the choice is yours; plus, we turn necessity into a virtue by simply not autoupdating at all. The suggestion that Firefox could have been kept as a perpetual ESR and the new hotness used as a rebranded browser specifically for their bleeding edge market just as we do is very well taken, but it's too late now. Like all organizations that get too big for their britches, the goal of MoFo is now its continued survival at the cost of the goals that brought them to this point in the first place. But it's still the most trustworthy browser and for all its flaws no one has a bad word to say about Mozilla's ethical positions, so that's why we still put up with it. Gecko shows no signs of being co-opted for some nefarious goal, unlike WebKit (trusted builders like Tobias excepted, of course).

As I intimated in our first entry on Judgment Day, however, there are some clouds growing on the horizon for our continued operation. After internal discussion, I've negotiated a compromise with Mozilla where on paper 17 will be 10.6 only (by changing the minimum system version in the application .plist), but the 10.5-specific code will move into the ESR where we will pick it up again. Leopard support, thus, will officially end with Firefox 17; 10.5 will not be officially supported by the next Firefox ESR. It is likely we will also inherit the 10.5 Intel users orphaned by this, and time will tell just how much of the 10.6-specific APIs we can code around. Related to this is that we are carrying more and more hacks in our changesets to deal with gcc 4.0.1, and while I am committed to keeping 17 stable buildable with it, we will be jettisoning it for any unstable releases after that. The problem, however, is what we will replace it with; Mozilla already plans to replace gcc 4.2 when 10.5 support goes away with clang 3.1, and may also use it on Linux, leaving Android as the only OS still building with gcc through the NDK. Tobias' testing shows that gcc 4.6 will work, but gcc 4.7 does not. I haven't even tested this, mind you, and probably won't until 17 gets off the ground.

We have always known there would come a day when we could not advance the browser, and when that day comes the last unstable branch will become the new stable branch and we will drop to feature parity. I am very doubtful we will make it to 24ESR, if there is one, so that time will come between 17 and then. However, I again reiterate there will be security and feature updates after that day (what comes after Judgment Day?), because I depend on this browser, so I will still be working on it.

Incidentally, I now get the occasional request to build an Intel 10.4Fx. I'm not going to do this myself, and I'm not even interested in building a universal version; I'm not even sure we want to distribute it, lest we be asked to support it. However, I would be very happy to furnish technical assistance to such an undertaking if someone wanted to build a downstream project based on our work. Josh Juran had looked at this, but I don't think he got too far off the ground, so I'm leaving it open to other interested technically capable users. The most important parts are to restore the SSE code and the x86 methodjit backend.

In other news, Mozilla is starting to wind down Thunderbird to an unclear fate. There will still be a 17ESR of Thunderbird, but it's not really obvious what will happen to it after that and Mozilla has stated that more details won't be available until September. In fairness, there's not a lot of innovation left in the mail client arena to be sure, and maybe this is just a recognition of that; I don't personally use Tenfourbird or Thunderbird, but many people do, so I hope that it at least remains in perpetual maintenance even if it doesn't really evolve much further.

Finally, in PowerPC threat and security news, F-Secure has discovered a Java based malware launcher with a PowerPC payload. Yes, you read this right: to infect Intel systems, this trojan actually requires Rosetta; it cannot infect 10.7 or 10.8, but it can infect us directly. Now, there's nothing really special about this trojan's modus operandi -- unlike Flashback, which used a Java flaw to allow an otherwise impotent applet to escalate its privileges, this is simply a signed Java applet working as designed. If you willingly and foolishly execute a Java applet signed by an untrustworthy source requesting full access to your machine, despite the very prominent warning you will get from Mac OS X, you are too stupid to use a computer and should immediately move to Burkina Faso where you can't hurt anyone. The payload is a previously unknown APT called GetShell.A and it is all good old fashioned PowerPC code. Fortunately, as long as you are reasonably careful, there should be little practical risk from this attack.

Watch for releases this week.