Uproar-a australis: Australis lands, cars and cities burn, people die in streets

UPDATE: Australis is now targeted for Firefox 29.

If you've been living in a cave with D.B. Cooper counting his inflation-ravaged ill-gotten gains over the weekend, you may have missed the news that Australis landed in Firefox slated for Fx28, and appears to be sticking (I didn't make this announcement on the day of because I suspected it would be backed out for bustage, and it looks like my guess was wrong). Australis, of course, is Mozilla's new interface for Firefox, radically replacing the current appearance which has remained relatively unchanged since a minor facelift and modifications for Firefox 4.

The response has been decidedly mixed at best. One particularly dire estimate from Mozilla's own feedback system says only 20% of Firefox nightly users like the changes, though this is a small sample of apparently really p*ssed off people, and may reflect bugs or add-on incompatibility along with the differences in appearance. Still, these are the users most likely to enjoy new shiny and least likely to be offended by change purely for being change; they're on the nightly build branch, after all, so this early feedback bodes poorly. Australis' most controversial changes include larger icons and larger tabs, no more small icons mode, removal of certain customization options like hiding the navigation bar, and completely dispensing with the add-on bar altogether (marked for death in Fx4 but restored as an option after fierce complaints; it now appears that the stay of execution has expired). Oh, and tabs on the bottom? That's been marginalized for some time and now it's gone too.

Irked users are, of course, fighting back (paradoxically demonstrating Mozilla's continued high level of customizability even post-Australis); there is already an add-on to restore most of what was lost, and the most incensed Nightly users are moving over to the holly branch, which is a temporary stopgap branch of Fx28 using the previous chrome created by Mozilla in case a backout was required. (It is not likely to persist much longer now.) At least one custom Firefox rebuilder, Pale Moon, is making their intentional omission of Australis a selling point.

Australis just adds to our porting woes. Remember, we are committed to 10.4 support; there will not be a 10.5-only TenFourFox, at least not from me. Although initially I had optimism that the technical issues could be worked around, we already have at least one glitch due to the underlying widget changes (issue 247) and future changes will likely make this worse. There are also new dependencies on components of the Objective-C 2.0 runtime (10.5+) which probably can't be effectively implemented for 10.4.

Australis also has practical considerations for our older machines. Its performance is judged to be similar to old Firefox, but this is on systems with hardware acceleration; software is now a fallback, and we render entirely in software. The larger tabs and icons have a big impact on machines limited to fixed resolutions, particularly the iBooks and iMacs: this iMac G4 I'm typing on has only a 1024x768 display, and tabs this large will impair its useability and reduce the content area. If you want to get an idea of the magnitude of this effect, load up Tenfourbird, the tabs implementation of which Australis is approximately based upon. (By the way, this is not the fault of our Anonymous Builder in the Land of the Rising Sun; this is the way Thunderbird ships, and as an avid user of Tenfourbird for Usenet, we are glad to have him in the 10.4Fx ecosystem. Arigatoo gozaimashita.) Look at the swooping tabs in Tenfourbird. Those are, roughly, the size of the Australis tabs. See how much more real estate they take up? While you're at it, increase the size of the icons if you're in small icons mode, maybe throw a few more icons up there (that's where your addons will go). What does that do for your productivity?

In the early iterations I thought Australis would be a nice step forward and make the browser more attractive and pleasant to use. And, arguably, it does at least modernize the appearance, even if (once again) it's clearly a design decision driven by Google Chrome. But I am now rather repelled, personally, by the significant functionality cost and furthermore quite alarmed we will be unable to make it operate reasonably well, if at all, on a 10.4 Macintosh. Off-main thread compositing is also looming on the horizon, which may not be compatible with our threading model without significant work (and has a big chance of causing graphical glitches on software renderers), and I've only made a small amount of progress on getting JavaScript in Firefox 26 to compile without backing out the patch I don't want to back out.

It's not a good day.

MacPorts bustage and trouble with 26

Floodgap was again down today because of a nasty winter storm that knocked the power out for almost twelve hours (the UPSes are, best case, good for maybe three). There was some hideous arcing early this morning but it doesn't look like there was any hardware damage. Unfortunately, the wind is still really howling outside and I hope we don't have a repeat episode tonight.

For 24.2.0 final, scheduled for 10 December, there will be a total of three tweaks on tap: increasing the garbage collection timeslice (as mentioned before), which should also help reduce memory usage by cleaning up more fully; again locking cores to one; and removing the blurred boxshadow from the video stand-alone document so that playback doesn't chug when the blur gets invalidated and must be redrawn. No other critical bugs have cropped up.

That's the good news. After this, it's all bad news. The port for 26 is running aground; JavaScript does not compile with either gcc 4.6.3, 4.6.4 or 4.8.2 due to a security patch of arguable utility. This patch does not compile when applied to 24 either, but we can back it out safely on 24 because no functionality actually relies on it, and there is some question over whether the problem it fixes is even exploitable. This isn't true for 26 because it may be an issue for generational garbage collection, which is imminent in Firefox, and code likely does depend on it. I am waiting for Mozilla's opinion since I'm not sure how to safely rewrite the code so that it compiles and is forward-proofed.

Oh, but before I could do that, trying to install gcc 4.8.2 caused MacPorts to try to rebuild Perl 5.12, which failed (even though I already had it on the system) due to a linker problem with Xcode 2.5. Forcing the install caused it to fail building cloog due to bad isl headers. Upgrading isl manually enabled it to complete and then I could build the other prerequisites and told it to ignore the Perl one, and finally I successfully built gcc 4.8.2 ... which then broke gcc 4.6.3 because of the new compiler libraries. One rebuild, a lot of cold sweat and about 24 hours later, the toolchain is working again and I'm crosschecking the libraries to make sure. As a result, we're on gcc 4.6.4 but 4.6.3 will still be supported, since it was known to work. All this to say that you should be very careful about MacPorts updates right now -- it is doubtful anyone is routinely testing port changes, let alone new ports, against 10.4 or 10.5 and several ports are already demonstrably busted. I need to backup /opt and then I'll try to submit fixes to the portfiles for 10.4 as I have copious spare time. It may be worth our while to generate a binary set of the toolchain components that can be installed separately to guard against this, since it will almost certainly happen again in the future.

I have a low threshold for not advancing to 26 even if it works, mostly because I don't want to be dropping source parity on a non-ESR release so close to an existing ESR branch, and because some of the stuff for Australis that is landing now is alarming and may not even be workable for 10.5, let alone 10.4, which may force our hand anyway. (But hey, I predicted our demise for Firefox 5, 10 and 19, and we made it through all of those releases; still, we've existed much longer than we've had a right to.) I'll make that decision based on what changes I have to make to get 26 to work. If these changes are unacceptable or impossible (or I can't figure out what to do in time), or the resulting product is iffy, then we stay on 24 and we go to feature parity. I'll decide this after 24.2.0 comes out.

The MacTubes Enabler. Because we loved all those damn System Enablers back in the day.

H.264 is still several cycles away -- IonMonkey and Australis have highest priority for new development. But that doesn't mean we shouldn't look for shortcuts, like the QuickTime Enabler, which has gradually evolved over time into a general purpose tool for pushing video to QuickTime for external decoding (where possible, of course, and it isn't always).

In that vein many of you have explored and used MacTubes, which is a delightful tool for direct playback of YouTube videos. It's kept up to date with Google's frequent screwings around on the backend, it has a variety of playback methods including Flash, WebKit and QuickTime, and it's probably the highest performance way to play YouTube videos on a Power Mac (even HD is possible with sufficient grunt). I downloaded the source to play with and discovered it can be fed a URL through Launch Services, so I tried that, and it worked -- it figured out the video location and automatically started playing it.

Thus, may I present the MacTubes Enabler for your consideration. The MTE reuses a bit of the Carbon-CoreFoundation-JavaScript glue from the QTE, but is far simpler: it just pushes the YouTube page you're on to MacTubes, and MacTubes does the heavy lifting and starts playing it. Piece of cake.

The MTE also has a trick that the QTE doesn't yet: you can direct it to start playing in MacTubes and close the tab in one step. One big irritation involving the QTE, and with YouTube in particular, is that YouTube will start streaming the WebM video while the QTE is trying to load the H.264 version at the same time (this can be bad enough on a slow link to make QuickTime think there's no data and give up). There used to be browser addons that would defeat YouTube's autoplay feature, but none of them work anymore and Google seems to be trying to bust these techniques also, thus this feature (that will always work): now the full bandwidth is devoted to streaming the video through MacTubes. If people like this feature, I'll add it to the QTE. (Another idea might be to back up to the previous page, or if there is none, then close it. What do you think?)

The MTE does not replace the QTE (and, for that matter, the MTE is completely independent of the QTE; you can have both of them installed simultaneously, even): you'll still need the QTE to play non-YouTube HTML5 video, which MacTubes doesn't handle, and if MacTubes becomes unsupported one day we'll still need QuickTime. (However, I'm able to build MacTubes from source on my G5 independently, so that's a solveable problem if its author someday decides to hang up his hat.) I'm also not planning to merge the MTE and the QTE for the foreseeable future because it's nice to have a playback alternative, and saving video and getting to HD formats is a little easier in QuickTime Player.

Consider the MTE a beta and give it a spin. Download it from its wiki page. The MTE requires TenFourFox 24. Test it out on Jean-Claude Van Damme injuring himself, or maybe some of MTV's finest cartoons when they actually played music.

17.0.11 is live. I'm going to make one tiny change to garbage collection scheduling to help intermittent stalls prior to release of 24.2.0, which should be the first public release. It looks like we will have a mostly full set of langpacks, too, so a "great work, guys" to Chris and all the localizers.

17.0.11 rises from the grave like an undead zombie

Mozilla is issuing a proactive fix for a security issue with secured connections that affects all versions of Firefox going back to ESR17. While nothing is currently exploiting it, the issue was inadvertently disclosed through a publicly visible commit, so the decision was made for an urgent point release and we're going to go ahead and match that for 17. I don't know when this will hit the release channel officially but I will probably push the button for us Friday night or Saturday. There is only that one change in this release and the 17.0.9 changesets still apply. Downloads, release notes (for the last time, hopefully).

24.1.0 is affected by this also but it's going to be replaced by 24.2.0 in less than two weeks, so I'm going to simply monitor the situation for right now because the fix in question is merely proactive (and an exploit must be PPC OS X-specific). I have not had any more reports of menu bar freezes, so I am going to assume issue 248 is fixed by our hack. If you are a localizer, time is running out before we need to nail down the langpacks for launch. Tune in to issue 42 and/or issue 61 to coordinate with Chris.

I'm nearly done merging the new patches into what will hopefully become TenFourFox 26 and then we will be back on target for the new unstable branch, assuming it works. I'm still hoping for IonMonkey by Fx27 or Fx28 and I should have some time to get to this during the holidays. Still no word on the ETA for Australis.

Happy birthday to us

Celebrating three years since the initial release of TenFourFox 4.0 beta 7, on 8 November 2010! Yay us!

24.1.0 available (welcome to SourceForge)

24.1.0 is now available with the fix for issue 248. This didn't happen to me very often, but as discussed in the last post, it solved it when it did; if it isn't solving it for you, I need steps to reproduce. I'm going to keep on fiddling with issue 247 (Personas overpainting the window buttons) for a bit, but since it's entirely cosmetic this is a bug I can ship for the time being -- especially because I want to start work on Firefox 26 right away and kick off the next unstable series.

Oh, you didn't find it under the downloads tab? That's because it's now at our brand spanking old SourceForge files repository. It isn't as quick or clean as Google Code was, but it still has MD5/SHA1 hashes for you paranoid folks, it lets us organize by version, it has geographically distributed mirrors and it didn't cost me any freaking money. Get files from the 24.1.0 folder; the release notes are still at Google Code. Remember, only downloads have moved; everything else is staying at Google Code for the immediate future.

I am informed that Tenfourbird is indeed circulating a beta version of 24 too, and I'm delighted to see our anonymous builder in the Land of the Rising Sun has made the jump to the next ESR with us. It's just a coincidence that he uses SourceForge as well, by the way. Maybe.

And now for something completely different: iMac G4 versus mini G4 smackdown (plus: who's your Daddy, Carbon API)

The Santa Ana winds were kicking up in Southern California, and I know this because they apparently snarled the phone lines and knocked the T1 off yesterday, which is why Floodgap was down all evening and part of the morning and I haven't gotten much work done on 24.1. Sorry about that.

However, tonight I think I can finally announce I have a working fix for the menu bar freeze in issue 248, which I was able to trigger while writing this very blog post (indeed, it does seem heavy keyboarding is to blame); based on discussion with Steven Michaud at Mozilla (thanks, Steven!!) it looks like it's an operating system bug that we're now triggering more easily, and it's probably happened at least to a limited extent to every previous version of TenFourFox. 10.4 and it looks like 10.5 can get into a situation where it misdelivers events to the wrong control under circumstances I don't yet understand, so it was falsely feeding the mousedown on the menubar to the (invisible) popup window control we use for context menus and click-hold menus, never getting to the menubar. The result is the menubar appears to freeze even though everything else works. This is another case where the Mac's menubar being always at the top of the screen makes things very easy, because catching a click up there should never happen (the OS should have routed it to the menus first), and so interception was straightforward.

I couldn't figure out why that was happening, but I could figure out how to get around it. Analysis of Shark tracing on a working process and a stuck process show they both activate an internal undocumented Carbon API function called _NSHandleCarbonMenuEvent, but it doesn't activate any additional functions in the stuck browser while succeeding in the working browser. Disassembling the Carbon library using otool shows that it takes a single argument (in register r3) which I guessed was a Carbon EventRef. Apple doesn't document Carbon EventRefs and wants programmers to treat them as opaque types, but they do somewhat document older Mac OS EventRecords which still exist in OS X, and _NSHandleCarbonMenuEvent actually calls a documented conversion routine called ConvertEventRefToEventRecord to get an EventRecord that we could spy on. Stepping through it in the debugger, we could confirm that the single argument was indeed an EventRef and the Carbon event kind is stored at byte offset 16 (at least for PowerPC -- I don't know if this is true for x86).

After I was able to trigger the freeze again, I was able to see that the event _NSHandleCarbonMenuEvent was getting was a kind 2 event (a mouseup), not the kind 1 event (mousedown) it should have been receiving. My first thought was to monkeypatch the event type in memory, but since it was already getting the mouseup, we could just inject the orphaned mousedown instead. But how to get the orphaned Cocoa NSEvent our popup window intercepted into the Carbon system menu handler? Using Magic Hat to dump NSEvent, I discovered Apple has an undocumented [NSEvent _eventRef] method in 10.4 for getting the underlying Carbon EventRef (it works with 10.5, too, though 10.5 can just use [NSEvent eventRef]). So, when we get that misdirected event, we use that undocumented Objective-C method to get the EventRef and just feed it back into our undocumented Carbon function _NSHandleCarbonMenuEvent. It seems so simple when I put it that way. Ain't hacking operating systems great?

I don't know if this will work for 10.5, but I can't see any reason why not. We should have test builds up this weekend to make sure it takes care of the problem.

In other news, being a guy with more money than sense (I don't have very much sense at all), I'm expanding my stable of Power Macs. And if you like Power Macs as much as I do, this is the best time to do it. Intel Macs are starting to clog the market in the wake of 10.7/10.8 and people can't even give away Power Macs practically, so prices have plummeted on the used market and I'm stocking up.

My primary machine is still my quad G5, and I use an 12" iBook G4/1.33 on the road (occasionally with an ARM Chromebook with Crouton loaded over ChromeOS). However, the G5 sits in the office in the back of the house, and it's nice to have a second terminal around, so I have a 1GHz iMac G4 out in the commons where I eat and pay bills and such.

I think the iMac G4 is the best looking Power Mac ever made, hands down, better than the Twentieth Anniversary Macintosh which is a real looker (I have a TAM on my bedside table), and the 15" one I have has a perfect arm (not sagging!) and LCD, case and mechanism. But 1GHz is a little poky and a 256K L2 cache is even worse; my iBook G4, which on paper should be 33% faster, is about 50% faster despite having a slower frontside bus because it has double the L2 (Apple has always criminally undercached their designs; see also G5). So when a 1.5GHz G4 Mac mini cropped up on eBay in great shape with 1GB RAM and a 17" Apple Studio Display, I struck and nabbed the set for about $125. But which one is the better Power Mac?

• CPU: No question, the 1.5GHz G4 mini is already faster on clock speed, but also has 512K of L2 and the same 167MHz system bus; easily it's close to 75% faster and maybe more depending on the task. Even the top-end 1.25GHz iMac G4 still has just 256K of cache, so overclocking is of questionable utility; plus, all of the 17" and 20" iMac G4s are starting to show sagging in the arm due to the screen weight. iMac 0, mini 1.

• RAM: The mini is limited to 1GB in one stick. The iMac came with 512MB, 256MB in each slot; I have 1GB in the user-serviceable slot for 1.25GB and I have a stick ready to put in the top. This requires a little bit of disassembly, but the potential is there. iMac 1, mini 1.

• Video: The mini has an 64MB ATI Radeon 9200, while the iMac is still plodding along with a 32MB GeForce4 MX. Plus, 15 inches of screen real estate can be a little confining and using the iMac with an external monitor is heartbreaking. iMac 1, mini 2.

• Expandability: On first blush this looks like a tough call, but after some thought there is a clear winner. Both take relatively standard hard disks and optical drives, and both have 48-bit LBA. Neither machine has PCI slots; both have Ethernet and can come with WiFi, though only the mini offers Bluetooth as a built-in option (as it happens, this one has both WiFi and Bluetooth). Now, you could add WiFi or Bluetooth to either machine, but you need USB ports for that, and that's where the iMac nudges by: it has 3 USB 2.0 ports and two FireWire 400 ports, lots of room for stuff. The mini has only two USB 2.0 and one FW400 port, and one of the USB ports is occupied by the Apple Studio Display controller because the G4 mini doesn't have ADC. You could get around that by getting a different monitor or a hub, of course, but you're still losing a port for the keyboard and mouse, and your cost and inconvenience keeps going up. And, after all that, the G4 iMac has an external video port, too, and can use the Apple Pro Speakers (of which I have several pairs). iMac 2, mini 2.

• Serviceability: The mini is not too hard to work on (once you get over those hideous cracking noises prying open the case), but has a lot of screws to lose, and getting to the optical drive or hard disk can take a little bit of time. On the other hand, the weird form factor of the iMac means you need a lot of workspace and have to protect the LCD and bezel from getting scratched, and if you pull the guts out from the "cone" to get to the hard disk or the second RAM slot you usually need to reapply thermal paste to the heat sink. Neither is unrepairable, but neither is a paragon of repairability either compared with, say, an Outrigger Power Mac or the easy case opening of the Power Mac G3 and G4; call this a wash.

• Hotness: The 17" ASD has a real cool retro vibe, but the iMac G4 is just gorgeous. Pair it with the Pro Speakers and a nice white Pro Keyboard, and it looks great. The arm still supports the screen perfectly. Everyone who comes to my house comments on how nice it looks and how computers in general don't look that good anymore. And that matters. iMac 3, mini 2.

Maybe I'll just put the mini in the bedroom too.

The Cisco Kodec

H.264 has not been the strong suit of Mozilla browsers due to their (until recently) longstanding ban on the codec, and the reason is licensing: MPEG-LA wants money, and they'll sue you if you try to get around them, because the patents are still on the books.

There are various solutions to this problem. In TenFourFox, we have the QuickTime Enabler, which is admittedly clunky and doesn't always work, but because it plays natively in QuickTime Player means it can use its private GPU acceleration capability. On Linux and the *BSDs (great band name), there is GStreamer, and while GStreamer can be coerced into running on OS X, the worry about our using GStreamer's built-in H.264 implementation is that it may violate MPEG-LA's codec patent terms. Since I'm the ringleader, I'd be personally liable if they sent their lawyers over with K-Y jelly and rubber gloves. The way around that, of course, is to use a licensed component that's already on the system; Tobias had done some work on this for GStreamer in AuroraFox, and Mozilla is also doing some, although their approach depends on 10.6 APIs.

Or, have someone pay for the license. Mozilla has consistently refused to allow this option because even though they could probably afford it, their doing so would not grant a license to downstream projects (like us!) who would have to pay their own licensing fees. So a couple of days ago, Cisco said they'd do it because they have a lot invested in WebRTC, the web-based real time communications standard-in-waiting, and they want people to finally standardize on the One Codec To Rule Them All.

Now, before everyone gets excited, while it's still good news, it's not really all that good:

• The only licensed components is the pre-built binary libraries, which are, surprise surprise, not likely to be compatible with PowerPC OS X because Firefox isn't. For that matter, PowerPC Linux isn't on the list of "approved" operating systems either, and you can't just add Cisco's source code to the tree and take advantage of their largesse that way, even though it's open source (it's open source like Android is open source, which is to say, only to the minimum necessary); in RMS unhygienic neckbeard terms, it's gratis, not libre. As a somewhat troubling corollary, Firefox on Tier-1 platforms lacking H.264 support will now go out and grab a binary blob and automatically install it to play H.264 video; it doesn't come with the browser. There'd better be a damn lot of tamper checks on that, and I'll be the first one turning that off on my desktop PC at work.

• Cisco's guarantee doesn't cover the situation that some patent troll crops up and says they've got a piece of the patent outside of the MPEG-LA, and Cisco specifically disclaims their responsibility in that circumstance.

• The license is only for the MPEG-4 video codec. It doesn't cover AAC or MP3 or any other separately-licensed audio codec used for the MPEG-4 audio track, so this wouldn't play most of the videos that are out there by itself (or it would play them without sound). It's for WebRTC, something that we don't support well right now, and WebRTC uses Opus.

So we're not going to do much with this idea, noble as it appears. When IonMonkey is ready and we're sure Australis will work, then we'll work on adding GStreamer support fed through QuickTime so that the only thing we're distributing is the shim to QuickTime (and nothing that runs afoul of the license), and that should take care of the H.264 problem (but QuickTime Enabler will still be supported since it works better on slower systems).

In the meantime, I've stalled 24.1 because the speculative fix I whipped up for issue 248 doesn't fix the problem and I will try to get it out this coming week. Chris suspected a lot of typing causes the menu bar to freeze, and so far, that's the only commonality I've seen on the handful of times I've personally tripped it. If this is happening to you a lot, finding a reliable set of steps to reproduce will go a long way to getting this fixed. 24.2 is coming out, come heck or high water, working fully or no, in December; we're officially out of time.