Sweet 6 point oh een (or something)

The reason it's been quiet here lately is, of course, that I was working on porting Firefox 6.0, which hit the beta channel on Tuesday, and there it is. In fact, this post was written up in it.

6.0 is the first full iteration of Mozilla's rapid release strategy (i.e., a full 6 weeks at each stage), and yet, if Firefox 5 should really have been Firefox 4.1, this still feels like 4.2. Out of the box, the only major user facing feature is "highlighting" domain names in the URL bar (really, dimming the rest of the URL). This is another Chromism and I'm not really very fond of it personally. Mozilla is also introducing, as a trial balloon, a Permissions Manager accessible under about:permissions. However, if you're like me and have a lot of specific cookie permissions, it takes forever to load and is not significantly better than the old way with preferences; it's also not exposed in the UI anywhere.

Under the hood there are additional HTML5 elements now supported, most notably <progress>; WebSockets (which were pulled for security reasons in Fx4); enhanced developer tools, and MatchMedia support. And, well, that's about it.

The build is not going entirely smoothly. Tobias Netzel has shipped me a 64-bit version of the ported Xcode linker we use while I try to get a debug build mounted, but optimized builds do function, obviously. However, the debug build is exhausting the memory on the 8GB G5 buildhost, so this appears to be a 32-bit limitation. We may have to add a build requirement that the debug build be built with the 64-bit version of the linker, which would limit the machines that can build it, unfortunately. More on that as we sort this problem out.

Specific to us, I'm phoning this release in because Mozilla landed a lot of crap that tripped up porting our changesets. Among the new changes was splitting off some of the text handling features in the Cocoa widget code (bug 519972), which naturally upset the Tiger customizations I had made. I believe I've successfully dragged back all the 10.4-specific code that we need into the new places, but I'm still not convinced everything is correct. This took several days to rewrite, and we will have another set of rewrites to do in Firefox 8 related to it. On top of that, Mac OS X 10.7, which went golden master and is expected to emerge "any day now," has serious bugs in its implementation of ATSUI (bug 663688, currently sec-locked), which we must use in 10.4 because 10.4's secret Core Text support is incomplete. Mozilla thus rewrote much of the legacy font handling code we rely on in terms of Core Text, which blew up the compile on 10.4. I've hacked this back into submission, but it will break again because that whole section will be revised when 10.5 support is dropped from Firefox and I am unfortunately all but certain that will occur somewhere around Firefox 9, early next year. After all that work, and trying to move to a new house, I really haven't had time to work on more TenFourFox optimizations for this release. We should get a break in Firefox 7 (if we're still able to build it, of course), so if we get Fx7 to stand up as 10.4Fx 7, then I'm going to work on some more AltiVec improvements at that time.

That brings us to plugins. Mozilla has made the first change which will break some legacy plugins in bug 468678, which was a long-warned threat to disable resource files as a data exchange method in Mac plugins. Cursorily Flash and QuickTime don't seem affected in their recent versions, but people using old versions might not be so lucky, and other plugins depending on this will break. This is the first change of many that will erode plugin operation, so as threatened, this version turns plugins by default off and support for plugins ends. I have wired up a preference to reenable them which will be posted here, as I assume if you follow this blog that you are technically versed enough to understand they are no longer supported, may not work correctly, may not work at all in the future, and already have known bugs. More about that when I get 6 beta 1 polished for release, hopefully next week.

On the 5 front, Mozilla is ruminating about a 5.0.1 release to address the 10.7 issue I explained above. This is not decided yet, but my insiders tell me it's probably going to happen and would be a Mac-only release fixing that bug only. This does not affect us right now, but because it has the font changes in it, it requires us to backport our fixes for 6 to 5 which could be iffy if we need to build more versions from 5 (such as we find some showstopper in TenFourFox 6 that requires an interim 5.x security release to be made). This will also snarl our home builders, so we may need to issue a workaround for you folks as well. We'll deal with this if action is required. As a point of completeness, 4.0.3 remains the terminal release for TenFourFox 4.

Speaking of 5, David Fang, our indefatigable Fink porter, reports that TenFourFox 5 now builds on 10.5 and 10.4 from the Fink unstable tree, and he and his crew are getting 10.5 support backported to TenFourFox 4. So those of you who want to continue making custom builds, but are allergic to MacPorts, continue to have that option. Strong work!

Finally, Chris Trusch's legwork on the Java and TenFourFox 5 issue has culminated in Apple essentially admitting that they broke Java on 10.5 on purpose in bug 668639 (except, of course, for Safari). The solution is, natch, to upgrade to Snow Leopard, and Apple says that the problem is a "non-issue for PPC users, because Firefox 5 and Chrome only run on Intel Macs." Don't we just love those guys? If we end up releasing a 5.0.1, we will have a workaround in it, or you can use the symlink fix detailed in the thread. The code for it will be in 6, but Java will also become unsupported, as I expect Update 10 to be the final Java update for PowerPC.

Watch for builds next week, hopefully. There will be a period of brief downtime on Floodgap while I physically move the hardware to a new network and new data center, but the Google Code page and this blog will obviously remain in operation. I don't expect the network downtime to be more than 12-24 hours.