For better or worse: Power Mac G5, meet Australis. (Oh, pick him up off the ground, please, he crashed again.)

After a lot of sweat and screaming this weekend, I am relieved to state that Australis can be coerced to build and start on 10.4, and even do some basic browsing. Meet the very embryonic TenFourFox 29.

Unfortunately, right now it's hideously buggy. Issue 247, a known bug with personas where the traffic light buttons disappear at times, is prominent in every window. I'd assimilate this as a feature except that it sometimes will partially paint them and sometimes not at all, so we'll have to find something that makes it better. The background colour of the window is wrong, too; it always appears inactive, so the tabs look like they're not attached to anything. Icons in the menus look totally screwed up though they appear properly in the main window, and it also has random crashes on some web pages that look like an interaction with the font code we had to hack. But it does build, it does link, and the chances of there being a TenFourFox 31ESR are now better than even money. Once the browser is halfway stable, I'm going to pull the beta and rewrite the changesets. (Ignore the Aurora livery; we don't have special TenFourFox livery for aurora builds since we rarely issue them.)

Linux users, my success is bad news for you, however: this means that bug 961488 which is preventing Firefox from running on Linux/ppc32 is Linux-specific (and possibly affects *BSD as well) because I didn't trigger it in TenFourFox. Hopefully one of you figures it out. I left a place to start looking in that bug.

While I've only used it briefly I'm pleasantly surprised to note that it doesn't perform badly, considering, since this is a debug build and only trivially optimized. It's obviously much more wasteful of screen real estate than 24, but this is what we have to live with, and there are themes to revert it for those of you who already know you won't like it. Personally, I don't like it either (on my 10.6 machine as well) because it smacks of Chrome and it's a bit gauche, but I can live with it, and there are admittedly some nice things about it.

One final note of concern: there is a problem looming on the horizon, and it's another issue with our linker (issue 266); once again, Mozilla has overbloated XUL to the point where it won't link with our tools. The offender appears to be the newly-enabled International Components for Unicode support (which isn't in 24; this doesn't have anything to do with localization per se), which increases XUL by 10-20MB and makes the linker run out of room to link branches together. Mozilla does not install ICU support on Android or FirefoxOS, which is fortunate because therefore they must allow building without it and it's not likely it will be mandatory for Firefox 31ESR either, but we'll have to deal with the problem sooner or later because other future features might bulk the browser up too. If we can't link the browser, we can't build the browser, and we'd have to drop source parity.

Speaking of FirefoxOS, I did get it installed finally on the Geeksphone Revolution, which I have since christened the Revulsion because it sucks. In spite of the lousy hardware, however, FirefoxOS isn't bad at all; I'll have a review blog post up later this week. Still waiting for one last tool to do the service work on the G5, which I will also write up since I know some of you have asked about that too.

Update on 29

After a lot of sweating, JavaScript in TenFourFox 29 now runs with PPCBC once again. There seem to be some performance improvements, too, to the tune of about 5-8% on V8. Not bad. Now to get the rest of the browser up. No ETA on that yet.

The refurbished G5 spare is doing well; even in Highest performance it is fairly quiet by comparison, and in Reduced mode the loudest fan in it is actually the video card's. I'm waiting for tools I have on backorder to remove the dying processor assembly from the original quad G5 and I actually located several Apple-certified Refurbished complete assemblies with heatsinks and fully serviced liquid cooling systems, so I should have some tested-good spares that pass thermal calibration to substitute in (and I won't have to service the older one quite so urgently). I'll have some notes and a little bonus toy to play with in the very near future.

24.4.0 available

24.4.0 is now available, which fixes a number of internal issues (including backing out the user agent change) and the security fallout from Pwn2Own. Downloads on SourceForge, as always. Assuming all goes well, this will be converted to release Monday night Pacific time.

Because of the late release of 24, I haven't had much additional time to work on 29, and my G5 is showing signs that its liquid cooling system will need imminent service. The good news is, I keep lots of spares. A blog post will follow.

And now for something completely different: Geeksphone Revolution review (i.e., don't buy it)

And that's the review! Thanks for reading! (I'll be here all week!)

I have hope for FirefoxOS still, that there can be a fourth way other than the locked-down walled gardens of Windows Phone and iOS, and the practically locked-down walled Google Play Services garden of Android. And plus, given how privy our phones are to our intimate data, do we really trust Google, or Microsoft, or even Apple, to safeguard that critical personal information? But while Mozilla has more trust than any of those three, if there is no hardware running FxOS natively (that doesn't need it to be flashed on like Cyanogen) it will never gain any market traction because no one wants to have to flash their phone right out of the box.

To date, it has taken me literally one entire year to get a FirefoxOS phone. I tried to order a Peak when they first came out, and they were sold out within hours. Four months later, I finally got in a preorder for a Peak Plus. After picking their nose for several months, Geeksphone apologetically said that they were not going to be able to meet certification for it, and would I like my money back or get a free Revolution instead, their next generation phone (which at that time had no specs page)? Sure, said I, still desirous of any FirefoxOS device at all, I would like a free Revolution instead, your next generation phone, and they said okay, and then nothing.

And then it finally arrived today and I eagerly opened it up ... and ...

WAT.

Yes, that's exactly what you think it is on the lower right. That's an Intel inside logo on its plasticky hide. It's not an ARM device like the Peak or Peak Plus. It's an Intel Atom Z2560 that tops out at a finger-tapping 1.6GHz. It's a farking netbook in a flimsy handheld.

But, you know, if it has a good Firefox OS experience, I can forgive the fact it runs my least favourite processor family ever. I could maybe even forgive this:

Yeah, that's the startup sequence. Pretty gauche, huh?

Yes, gritting my teeth, I could forgive all that. I could forgive the cheap-o feeling case which felt like it would crack getting the back off to put the battery in. I could forgive the pixelicious 540x960 qHD screen which looks like ass compared to my 1080p Nexus 5 (and despite allegedly being an IPS LCD has a weird blue tint). I could forgive the icky CPU. I could forgive the 1GB of RAM, and in fairness, it does, at least, come with a MicroSD slot to supplement the 16GB flash. I could forgive all of these sins if it only came up in Firefox OS, which is in fact the only thing I bought it for. But no. It comes up in this:

It's bloody Android. And not even full Android: it's (pre-rooted, at least) AOSP Android 4.2. No Google apps, no custom apps. Nothing else. It comes with everything you see here and only that. And there's no way to dual-boot FirefoxOS out of the box, even though Geeksphone advertises it with FxOS on their very own web store!

Geeksphone, you suck. If I'd wanted an Android device, I'd have bought one. And in fact I have one, the stellar $350 Nexus 5, currently the best deal in Android devices ever and outclasses the $300 (€222) Revolution in virtually every metric. I bought this device to run FxOS and it's advertised to run it, but not only does it not come with it it also doesn't even include instructions on how to do so. Considering I started this entire adventure with the FxOS-specific Peak Plus, the least Geeksphone could have done after keeping my money for months is to include a MicroSD card with an Intel FirefoxOS build, instructions and a thank-you. Instead I have a piece of crap that isn't even fit to be a doorstop or a paperweight, let alone a decent smartphone. I'd say something about the battery or camera if this were a real review and not a rant, but I turned it off in disgust after five minutes, and I bet the camera's as lousy as the screen is. (Pro-tip: the camera plastic lens is covered with a plastic protector which you need to remove with the back off.)

So, when I get around to it after I stop fuming, I'll go and get a 16GB MicroSD card and try putting FxOS on it and if I brick it, I guess I'll use it for target practice. Mozilla needs to find a better hardware partner than Geeksphone. They really do. To be continued when I'm not so furious.

Pwn2OwnAPCUDidn'tWant

Pwn2Own is in full swing, so that you too can win inferior x86 hardware by cracking it (and/or cash money), and it looks like Firefox has fallen. Details of the flaws are being reviewed internally, but I think I can say without violating confidences that one of the proofs-of-concept is pretty inventive and unfortunately cross-platform -- even though it (ab)uses components we don't fully support, these components are enabled, so the attack actually works against us too as confirmed on my G5.

Because Zero-Day Initiative is planning to pay for every exploit, even ones that don't "win," we can expect more attacks from this year's hijinx and hilarity. This may mean that 24.4 will be delayed, which will also hopefully have our own fixes for issues 260 and 261, along with backing out the user agent change (issue 259). I'm still hoping for a weekend release in time for the usual switchover next Monday night.

I haven't been able to get 29 up and running in time for an aurora. All the patches are down, which required restoring our WebRTC QuickTime backend, our AltiVec WebM acceleration interfaces, portions of our ATSUI webfont support and the Color Manager colour management code, but on top of that there were a lot of changes in JavaScript I have to account for and it's still not building yet. I'm shooting for beta, maybe, and then a 31 aurora; at least we have 31.0 and 31.1 to get it working before 24ESR ends support. I still don't know yet if Australis can be coerced to work on Tiger, and the biggest problem reported in 29 relevant to us is an endian problem in handles which also affects PowerPC Linux that completely prevents the browser from starting. No one has been able to figure this out yet and I won't be able to debug it myself until I get the browser to build (if it will on 10.4), so technically minded PPC Linux users in the audience might want to have a look at this or you won't have a Firefox 29 either.

Apple takes the Snow Leopard outside and shoots it in violation of the Endangered Species Act

Recall from our last blog entry on the OS X SSL issue that the notorious goto fail; bug only affects 10.9 and up. Finally 10.9.2 fixed this, and as usual Apple simultaneously issued security rollups for issues in its other supported OS X versions, 10.7 and 10.8 ... and nothing for 10.6. That's important, because even though 10.7 and 10.8 were not affected by the SSL bug, they were affected by other vulnerabilities that were not patched in 10.6. While Apple is notorious for never publishing an OS support roadmap, those of us who lived through the end of 10.4 and 10.5 know what this means: Snow Leopard has gone to that great cancerous pancreas in the sky, even though it appears you can still purchase it from Apple.

(Interestingly, that list of security fixes above includes several vulnerabilities in Apple Type Services, of which at least a couple likely are in 10.4 and 10.5 in some manner. However, Mozilla includes a type sanitizer to guard against exactly this sort of malicious font data attack, so TenFourFox, at least, cannot be exploited in this manner even if a PowerPC-specific attack were designed.)

Since 10.6 can't run on any Power Mac, I'm not going to bemoan its loss specifically except to say that my token Intel Core2Duo mini circa 2007 runs 10.6.8 and will continue to, running Linux and Windows 7 in virtual machines; I despise Lion and (to a lesser extent) Mountain Lion and Mavericks for a variety of reasons, and Snow Leopard is the last hurrah for any PowerPC support in OS X thanks to Apple refusing to pay IBM/Transitive any more per-user seats for Rosetta. The real relevance to us is whether Mozilla will continue to support 10.6, because once 10.6 is dropped all supported Macs will be 64-bit and have video acceleration, two things that do not apply to our userbase, to say nothing of the widget changes which will no doubt follow and will almost certainly impact compatibility.

Mozilla's decision to withdraw support has historically been a function of the remaining userbase and what competitors have done. For example, when they dropped 10.4 for Firefox 4, the Tiger install base had already been declining slowly for some time and Google had never supported Chrome on 10.4, even on Intel. Interestingly, Apple is discontinuing Snow Leopard support at a time when 19% of the Mac world still uses it (thanks for the shout-out, Ars Technica!), and in fact this number has declined very little from November 2012 when 10.6 commanded around 21%. We can speculate about why it continues to hang on in the comments, but the most frequently cited are disgust over Lion's changes, hardware incompatibility and need for PowerPC support. Because Safari no longer gets updates, as a result both Firefox and Chrome (which also still supports 10.6) are likely to accumulate large numbers of Snow Leopard holdouts: almost exactly a year ago, 43% of Firefox's users were on 10.6, and assuming the decline is proportional, even in the worst case a whopping 39% of Firefox's users are likely to still be rocking the Snowy today. For that matter, it is also entirely possible that proportion may actually increase in the near term from displaced 10.6 users seeking a safe haven. Until Google decides to kick out 10.6 users, it is very unlikely Mozilla will do so unilaterally either, or at least not until somewhere in the 38ESR timeframe. And ultimately that's good news for us.

I am slowly working through the 29 port. Mozilla not only landed Australis but also made further changes to font support, ripped out the old Color Manager code we use for colour management (so I had to restore that) and upgraded libvpx which upset our custom AltiVec acceleration and I'm still labouriously trying to piece that back together. Meanwhile, Operation Garbage Collect Better is now at the following settings:

javascript.options.mem.gc_incremental_slice_ms;100
browser.sessionstore.interval;20000
browser.sessionstore.max_tabs_undo;2
browser.sessionstore.max_windows_undo;2

There is still a slow memory creep up to a unstable maximum, but browser performance is better, and garbage collection runs much less frequently. You can try these settings now if you like, and I think this set is much less experimental, but remember to restart the browser after you alter them. If you're not game to do this to 24, they will be default in 29; I've been running them for over two weeks and the G5's CPU usage is much smoother, even in Reduced power, so I am confident that they are solid enough at least for the beta audience.

SSafari SSL SSucks

Apple apparently created a major bug in the OS X SSL stack in 10.9, a one-line error that causes certain kinds of SSL handshakes to never fail. Because of the nature of the SSL failure, you can't prove that the server possesses the certificate's private key matching the public key it advertised in the handshake. This is a severe flaw and makes man-in-the-middle SSL attacks greatly facilitated.

Apple has fixed this in iOS, but to date they have not fixed it in OS X. Fortunately, the error was newly introduced in 10.9 and earlier versions of OS X are not vulnerable -- you can prove that with this test site, appropriately named gotofail.com, which tries to trigger the bug. That said, you will notice that the error isn't actually in WebKit ... it's in the operating system security library.

I think this bears repeating, because anything that uses the operating system libraries to securely access the network could be vulnerable to other security flaws. Safari, for example, is precisely in this situation; WebKit does not implement SSL per se, and certainly not in the way that Mozilla does. Every time you update TenFourFox (and for that matter SeaMonkeyPPC), you get an updated network library, current security certificates and an up-to-date SSL implementation. Although Leopard WebKit at least fixes the problems with WebKit proper it cannot defend against a deficiency in, say, NSURL, and if one were discovered then you would be vulnerable if you use Safari or any other application accessing the network in that manner, even if you have Leopard WebKit installed. (Even OmniWeb, which embeds its own custom WebKit framework, suffers from this problem, and it is highly unlikely OmniWeb will issue future releases for 10.4.)

Because Tobias no longer has the resources to maintain WebKit for Tiger, I think this bug serves as a warning that 10.4 users should not Safari any longer for any purpose, and even for 10.5, if you depend on your Power Mac for banking or paying bills I would look at something with a more robust secure network implementation for those tasks. This failure (even though it's on 10.9) demonstrates in a painfully clear manner that the strength of your encryption in virtually all WebKit-based browsers is entirely dependent on an operating system component that on Power Macs has not been updated in almost three years.

Thanks to those of you who have reported your tests with garbage collection optimization. Turning off incremental GC does not appear to be an option; it stalls out too much after awhile, even worse than incremental GC. Increasing the time slice to 100ms does not seem to make anything worse, and pairing it with reducing browser.sessionstore.max_tabs_undo to, say, 2, does seem to allow the browser to recover memory a bit better. (There is still an issue with slow creep up to an unpredictable maximum even when the browser is idle, and it's hard to determine if the operating system or the browser is doing this or a combination of both.) These prefs make significant changes to the browser's behaviour, so as stated before they will not appear in the current stable branch. Remember to restart your browser after making changes to them.

Finally, and almost unexpectedly, SourceForge named us one of their Projects of the Week. I know some of you are frustrated with SourceForge's download system and the pages and advertising are certainly much more heavy than they were on Google Code, but they welcomed orphan projects like us, the site administration has reached out to me directly, and little kindnesses like this show they've supported us in a way Google never did. Plus, $FREE is a powerful motivator, even if it comes with drawbacks. Hopefully they can fix some of the network issues on their mirrors that some of you have experienced.

I pulled Firefox 29 from Aurora a couple days ago and I will be uploading 26 changesets when I get a chance later today, so watch for them. This includes a very preliminary, awfully buggy, only partially working implementation of IonMonkey, but you must run it in gdb7 because it has trap opcodes. One way or another, I should have an idea very quickly if Australis is going to be in any way workable.