Ja-va hoo-ha

10.0.7 is final as of now, btw.

There is a lot of scrambling with the browser authors about what to do with a new 0-day Java exploit that is circulating and is already part of at least two penetration toolkits. The flaw only exists in Java 1.7, which was never distributed with any PowerPC version of Mac OS X (though you can install an OpenJDK version of it), but because of other flaws you should make sure that the Java plugin is off and of course we "ship safe" because plugins are already disabled by default anyway. If Mozilla chemspills for this issue, we will probably not follow suit unless there are other changes related to it we want to capture.

10.0.7 available

Je suis a bit fromaged off at Mozilla for, after nearly 24 hours of nothing and releasing apparently deceptive notes from their channel triage meeting that seemed to indicate they were ready to go to build on the evening of 8/22, landing two more bugs after that on esr10. Naturally I had already pulled before then.

Review of the two bugs indicates one minor one, and the other one actually broke the tree at least once and is being watched for fallout on the ESR branch. This does not sound appropriate to land on the tree so late, I'm not going to go through 8 hours of rebuild for a minor issue and an issue that may cause us to rebuild later, both of which were in 10.x all along, and neither one appears to in and of themselves have a security impact. We will pick this up with any rebuild and/or scheduled 10.0.8.

Please try 10.0.7 on your system(s). It will become final on Monday.

15.0 available

15.0 is now available from the Downloads tab. Share and Enjoy the Release Notes.

Of note, Mozilla themselves disabled pdf.js prior to release, so it looks like it wasn't really ready for primetime after all. The interested can still reenable it from about:config.

Real life and a paycheque is interfering with my hacking time, so 10.0.7 will be a rush job. I'm hoping to have it up by Sunday or Monday and we should still make it on time. I plan to merge the changesets tonight and then run compiles surreptitiously from the field as I pretend to read office E-mail.

I'm still doing planning for 18.0, our "Judgment Day" release. Because we will be shipping a new C++ runtime and other components, this will require more memory, and while 1GB RAM has been a practical minimum (he admits with obvious pain) for some time it will be the supported minimum with 18.0. It may still work on systems with less RAM, but it will definitely be impaired, and we won't accept bug reports on those systems. Assuming 17.0 will still build with gcc 4.0.1, it will be the last version to support 512MB machines. You are on notice. we'll see how it goes, based on Comments

More info when the 17 aurora port begins. For now, please try 15.0 and wait for 10.0.7 this weekend.

Changesets for 15.0 available

Changesets for 15.0 are now available against mozilla-beta. Overall, although 15 had some trouble initially with Mozilla breaking us in some convoluted ways, almost all of that is either fixed or wallpapered. In addition, Ben has provided improved typed array code that combined with some microoptimizations is good enough to play the JavaScript version of Wolfenstein 3D lousy bastiches replaced the old <canvas> version with a WebGL one, so it won't run now at full speed on a G5 (which seems sad, but hey, with 10.4 you can play the 68K version in Classic ;) ). We are on schedule to deliver both 15.0 and 10.0.7 on time.

Job one is now to get to the next ESR, and I've decided we will skip 16 and go straight to 17-Aurora to ensure that we have enough cycles to get it working. After 15, there will be two or three 17 releases: definitely a 17 Aurora, maybe a 17 Beta, and then a 17-final which all stable users will be offered (so on the stable branch there will be 10.0.7, .8 and finally .9 to end our support of 10ESR). I will update the Roadmap with this information. Remember, builders, downstreamers and porters, even if we get 17 working with gcc 4.0.1, it will be the last version we support building with it (but assuming we do, it will be supported for the life of 17). More about that when I make a formal post about Judgment Day, which will occur when 18 hits Aurora.

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.