Saturday, July 21, 2012

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.

Saturday, July 14, 2012

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.

Friday, July 13, 2012

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.

Wednesday, July 11, 2012

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.