14.0 is 14.0.1, war is peace, etc.

For those wondering where 14.0.1 is, you've got it; 14.0 and 14.0.1 are the same, with the version difference merely for concordance with mobile.

15 is mostly done (a fix to typed arrays and WebM, some JavaScript tweaks and a widget bug), so the question is now what to do about 16. What might happen instead is that there will be a formal 17 aurora, a formal 17 beta, and then 17, and skip 16 altogether; there doesn't look like there are many breaking changes in 16 and frankly it is far more important we guarantee we successfully reach the next ESR.

Besides the fact that Mozilla has now officially flipped the switch and made 10.6.0 the minimum for Firefox 17, they are also switching to clang for OS X builds starting with Fx17 as well. As a fallback, Fx17 and presumably the ESR will still be compatible with gcc 4.2 (and we will do our darndest to maintain 4.0.1 compatibility for 17-stable), but Fx18 will require at least 4.4, and then only because of the Android NDK. Fortunately, Tobias has already done some work on this and I have an internal gcc 4.6.3 build working as of this evening; we will start using that for 18 once some minor issues are ironed out, or you can use the portfile in MacPorts for self-builds.

10.0.6 available, QTE goes beta, and more Mozilla soap operatics

The RC for 10.0.6 is now available. Please give it a spin. Assuming no issues, it will be released to the yearning masses on Monday evening. Here are the release notes.

As the release notes will intimate, 10.0.6 has the JIT latency patch and a preventative (hopefully) tweak to the JIT trampoline to avoid a crash which cropped up early in the 14.0 cycle. Unfortunately, 10.0.6 is also missing something now: the tracejit. Although severely gutted and not fully functional, TM was left in 10.x for purposes of comparison against JM+TI. However, one of the security patches in this release causes the tracejit to no longer compile and breaks the build, and I am not entirely certain it can be repaired even if it were worth it to repair, so this last remnant of TraceMonkey is now sadly gone. If you were one of those users who turned off JM+TI and turned on TM against my advice, you will no longer have JavaScript acceleration; it will simply run in the interpreter. It's time to come home and turn methodjit back on. Sorry. Remove your hats, and let us have a moment of silence for TraceMonkey, which brought us a long way.

(moment of silence)

I have also promoted the QuickTime Enabler to beta, and created a QTE wiki page to promote it to users. To maintain compatibility with 10.x, this is the same version (v.114) we used for the QTE alpha. Feedback from the larger user base will then be used to create a 17.0-specific QTE. Unfortunately, as I explained earlier, the Jetpack library I used to create the QTE does not lend itself to making the QTE a permanent part of the browser, so it will remain an optional add-on.

A postscript to the Mozilla drama I reported on two posts ago. Gervase Markham is a solid, stand-up guy who has helped us out several times, but I am unhappy with this blog post saying these kinds of Mozilla discussions should go underground. Moving soulsearching or controversial discussions like Jono's into a secured, less-public forum is the last thing that Mozilla needs. Besides the self-serving interest that having Mozilla discussions in public fora allows ecosystem projects like us to have a voice in things coming down the pike (none of us are paid Mozilla staffers and while I have a seat on Mozilla's security group, I am only a contributor and not a regular "Mozillian"), the upshot that should have been learned is that Mozilla didn't listen to community frustration until it boiled over. And Asa Dotzler, G-d love him, has regularly and often made controversial policy statements in public for freaking years; they just happen to be controversial statements that MoCo agrees with. Frankly, I don't think "a safe place to vent" is really the issue here.

More to the point, limiting these kind of discussions to secret dark corners makes the project just as closed as, say, WebKit, and increasingly Mozilla's openness is the only thing that makes it distinctive nowadays. I have long complained in this blog about public sniping of a project without involving the creators to make it better, but what's worse is insulating real discussion of real concerns away from constructive analysis. We're open here. We don't restrict comments, even if I totally disagree. We solicit them, for better or worse; just don't do it behind our back. If Mozilla pulls this kind of metadiscussion inwards, they will lose the community feeling and sense of open ownership that makes them unique. Weathering such discussion would be painful for anyone and it's hard to listen to, no doubt. But it's important that they do, and that process of public involvement is a big part of what makes Mozilla special.

14.0 available

14.0 is now available. I'm really tired, so just go grab it from the Downloads tab. Changesets for 14.0 and initial changesets for 15.0 are now available; 15.0 still has a lot of work to be done on it, but the browser does work and compile in both debug and opt. 10.0.6 will build overnight and be available tomorrow or Sunday.

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.

Uyghur Power Mac users: watch out

If you're in China's less well-behaved territories and you use a Power Mac, looks like the People's Glorious Malware Factory No. 1 has something for you too. Jokes aside, Kaspersky is reporting a Universal version of the MaControl trojan attached to E-mails apparently trying to spearphish Uyghur Mac users. Trojans aren't really anything new to our world, of course; there are a number of older trojans which will successfully run on and attack Power Macs, very few of which remain in the wild. MaControl, however, is an advanced persistent threat-type infection that has a long history of use by Chinese hacker-enforcers, and to my knowledge this is the first time that it has been made "available" to Power Mac users, meaning at least someone out there still remembers us in our little RISC foxhole. It may also be a recognition that in those far-flung regions older non-Intel Macs are probably still seeing significant usage, the Dalai Lama's karma-depleting use of inferior Intel technology notwithstanding. So be careful about strange E-mails bearing strange .apps.

For folks new to this blog, read previous comments on Power Mac Internet security here, specifically discussing OS X and built-in apps, and a little bit more here.

I am working on the Fx15 port a bit early, which is being bogged down by the MPL license change invalidating many of our patches and DOM event changes requiring some big surgery to widget/. More on that later. However, we are still on schedule for an Fx14/10.0.6 release around July 13, and Classilla users will also be happy to hear that several major security flaws have been eradicated from 9.3.1 so far; the audit is now almost to the Mozilla 1.8 era and the review process should get faster then as many of the flaws will start to cover code that doesn't exist in Classilla.

As far as Firefox itself goes, no decision has been reached so far about 10.5 support. You'll be the first to know.

BTW: 100th post!

14.0 changesets available and rumblings of Judgment Day

A snapshot of changesets for 14.0 (mozilla-beta) is now available. This is not a major release for Mozilla; about the only user-facing change of significance is that favicons in the address bar are now replaced with a security indicator (globe means insecure; padlock means SSL; green padlock with name means SSL with an EV cert). This is a good adjustment because a common support question is "where did the padlock go? am I secure?" and I think Mozilla got enough of these to reintroduce that reassurance. There are some performance adjustments and a few new CSS features, but other than that nothing amazingly impactful, and click-to-play turned out to be a non-issue for us.

The only other thing to note is that this release also adds support for GStreamer decoding, but it isn't enabled in any released builds, and I am not aware of a prefab PPC GStreamer library we can just use. I am very nervous about us maintaining our own GStreamer; I'd prefer to have that outside of the browser for legal reasons, and be aware that GStreamer only adds the codec -- it does not necessarily improve performance, and QTE will still be faster on those sites it supports. This would just be for those sites that QTE can't currently deal with, like Vimeo.

On our end, however, we have some fires to put out. This version does include the JavaScript compiler latency patch from issue 160 and a crash fix discovered during the investigation of issue 165, and both of these patches will also be in 10.0.6. (Between the latency patch and general improvements in 14, I am now able to blog again with the G5 in reduced performance, which is great for beating the Southern California heat in my home office. Unfortunately, it seems our aggressively small, not-quite-ABI-compliant stack frames are catching up with us, but I'd prefer to delay any invasive surgery at that level until IonMonkey.) Furthermore there are some breaking changes Tobias found in Fx15, so after this I will pull down a copy of the 15 alpha and try to get started on it early (plus, I want to add the QTE as part of the base browser in this release, which is not complicated, but not trivial). However, the biggest problem is that I had to actually comment code out and back out other Mozilla changes to avoid compiler bugs; gcc 4.0.1 is no longer able compile some components in content/ without crashing. Mercifully the code that I jettisoned was non-essential, but it's inevitable we will get something like this in code that actually makes a difference.

We need to also combine this with the Mozilla Mac developers getting more insistent about ending 10.5 support. The current proposal is now to end 10.5 support with Firefox 17, which would really suck, because we would have to add that stripped code back in immediately for what would have been our next stable release on 17ESR. Fortunately I am not the only one with that opinion, and no decision has been made. We need to be reasonable about this; Mozilla has a lot of hacks in their code to deal with 10.5 deficiencies, and it does cause them additional material work in that regard, so I understand their point of view. Nevertheless, if we can get them to hold off on dropping Leopard until Fx18, we will be in much better shape.

These are the first rumblings of what I will call, with my characteristic hyperbole, Judgment Day. Assuming Mozilla agrees to hold 10.5 support through 17, Fx18 will be a major reworking for us: we will need our own theme and widget to escape 10.6+ API hell, we may or may not need to start working on IonMonkey, and we will definitely move to gcc 4.6. All of these foundational adjustments are big-league port changes and will almost certainly introduce bugs and parity gaps, so we'll really need a stable footing for our proletariat while the plumbing gets reworked in the new unstable branch. The only question after that is whether there will be a 24ESR and Mozilla has not said. In my best Arnold Schwarzeneggar voice, I can only say that "we'll be back."

13.0.1 not planned

Mozilla is issuing a 13.0.1 for release probably by Friday to address bug 733614 and bug 756850. Allegedly bug 736731 (MS Messenger and Hotmail bustage) is also being addressed, but there is no code attached to that bug. Neither of these issues I consider heavy enough hitters to respin for unstable, and both of them will be picked up in 14 anyway, the port of which will start when "beta 8" (really beta 3 by any other name) comes out sometime next week.

13 has turned out to be another problematic release for our friends in Mountain View. Besides these issues above forcing a chemspill, which is never desirable, the highly hyped New Tab page is really unpopular in SUMO. Even considering the fact that the displeased are usually the most visible, New Tab comments are 76% negative. Fortunately, it is pretty easy to turn off with the cube icon at the top right, or by a dive into about:config (browser.newtabpage.enabled to false, or browser.newtab.url to about:blank), but someone apparently forgot to tell the peanut gallery. There are also sporadic reports of issues with SPDY on Gmail and Twitter.

With regard to 14, the changes are largely at the UI level. 14 introduces the first support for plugin click-to-play, but this isn't enabled by default, and it doesn't change the fact we don't support plugins anyhow (this just guards against drive-by attacks, not errant clicks, so I don't consider it to be enough of a satisfactory security solution with the state of PowerPC plugins). It also does some more rearranging of the deck chairs by changing the address bar iconography for secure sites, again, but the Awesome Bar is now smarter about hostnames and domains, and that is a welcome change; there is also initial support for the Pointer-Lock API for games, and some performance improvements. Note that those of you who have used the AuroraFox build on 10.5 will have probably seen this already. The big improvements are still not scheduled until Fx15, and Tobias' early work indicates we have some compatibility issues we will need to work out with the JIT plus bustage from the libvpx upgrade in that release, so I might start that port early to see how much damage there is.

In the meantime, the optimization in issue 160 for JavaScript has performed very well on the 7450 10.0.5 test build, so it will be rolled out for 14 and 10.0.6. Watch for 14 probably in about two weeks.