TenFourFoxBox 1.0

For those of you happily using the TenFourFoxBox beta, it's now time for 1.0 as promised.

TenFourFoxBox 1.0 is mostly a feature and bugfix update. You can update your foxboxes in place without losing information; just save the new foxbox over the old one, keeping the app name the same. Aside from various cosmetic tweaks, this release also fixes a problem with sites that try to enumerate navigator.* properties (Chase Bank being the most notorious), since doing so would barf when it got to navigator.mozApps as we didn't have that component loaded. Interestingly, SeaMonkey had this same problem in bug 1094714, which they solved by effectively importing the entire JavaScript webapps framework. That wasn't acceptable here where the whole point is to strip the browser down, so I got around this problem by creating a dummy stub XPCOM component to replace it and splicing that in. Much more lightweight!

In addition, a number of you apparently rename your TenFourFox builds to just TenFourFox.app, so this version will try that filename if the proper machine architecture is not found. If you really can't control for that either, make a copy of the browser as TenFourFoxBoxRunner.app and it will take precedence over any other executable (but remember to keep that copy up to date!).

Finally, there were also several requests for allowing URLs to be sent back or at least copied for the main browser's benefit. I'm weighing my options on how to push the URL through (Launch Services or otherwise), but you can at least now go to the Box menu and copy the current location URL to the clipboard, or right-click any link to do the same, which you can then paste into your browser of choice. Localization is still not yet supported because we're not yet to a string-freeze point, but we're getting close.

Remember to stop all foxboxes before you upgrade them, and make sure TenFourFox is still running before you start them back up if you want to have the main browser running parallel. Developers, look at the Makefile in the Things To Try: For Developers folder for how to automate foxbox creation and upgrades from the command line.

As of this release, TenFourFoxBox has an official home page and download site and you can grab 1.0 from there. Assuming no major issues by the end of this week, we'll start publicly rolling it out, and then I'll start the arduous trek towards TenFourFox 45. Meanwhile, for 38.6, there will be some updates to the font blacklist but so far no major bugs yet.

38.5.0 available, and maybe 45 as the swan song, in not too long

TenFourFox 38.5.0 is now available for testing (download, hashes, release notes). Remember to quit any foxboxes you have open before you update the browser, and start the browser before you start any foxboxes back up if you want to have the browser and foxboxes running simultaneously (the Dock gets a little confused otherwise). This version backs out the last of the debugging code from issue 308 (which also yields a small improvement to memory and speed), works around issue 307 to always dump .json bookmarks (now with the correct extension), and fixes the application menu in foxboxes and certain add-ons by importing the patch from Mozilla bug 1181977.

This version also enables MP3 audio support by default (we use the minimp3 decoder, which I hacked for our purposes since AudioToolbox in 10.4 does not understand MP3). There are already some known files that don't play in it that do play in QuickTime, so this appears to be a bug in minimp3. If you report MP3 files that don't work, please include the encoder so we have at least a chance at something analysable. If you don't, I'll still accept the report, but I may not do much with it unless it's glaringly obvious what about the file it doesn't like.

With 38.5, Firefox 45, the next ESR, moves out of nightly into aurora. Since Mozilla is only up to the point of doing A/B testing for multi-process Electrolysis in Fx44 beta, it seems unlikely that 45ESR will make Electrolysis mandatory, so that means I would be foolish to not make at least an attempt at porting it. This will require another toolchain upgrade like we did for TenFourFox 19. Fortunately, we do have a working gcc 4.8 in MacPorts and it does build and run 38 successfully without our current gcc 4.6 shim, and I'm working with Sevan Janiyan to get the Tiger pkgsrc gcc 4.9 functional (it seems to need updates to as and ld, since it will parse the source, but currently builds a defective XUL). I'm also looking into using Misty DeMeo's Tigerbrew gcc as an alternative. Either way, after the update for TenFourFoxBox and its official release I'll probably start working on trying to adapt 45ESR, which should give us plenty of time to have a functional beta out by 45.1, assuming it doesn't blow up in my face.

I am, however, going to call 45 the end of source parity, and this time I mean it. I know I've said "the end" lots of times in the past, but besides the fact Electrolysis won't compile as-is on 10.4 (and quite possibly will be a net negative even if it works), and Electrolysis will almost certainly be mandatory by 52ESR now, Mozilla is now importing code written in Rust into Gecko, not just C/C++. Although Rust allegedly supports PowerPC, it is only known to work on Linux (and there isn't a snapshot, rustc or cargo for it even there); it is not known to work, or have a snapshot available, for OS X/ppc, and then there's the matter of llvm on our same platform. Mercifully it does not appear any of the existing Rust code (which is already in the tree) will be required for 45ESR, but it does appear that new Rust code will replace a number of older C/C++ modules by 52ESR once Mozilla works out the build system kinks, making Rust a build requirement. This would be a showstopper for us and any other Tier-3 platform that lacks a Rust compiler (Solaris on SPARC? the remnants of OS/2?). It would also probably signal the end of 10.6 support in the near future, since by default the Rust standard library requires features Snow Leopard doesn't have (though there are ways around it).

Frankly, I'm not going to maintain a completely new compiler for a language I'm not fluent in and its runtime platform on top of a browser and debugger I'm already maintaining singlehandedly when we're already facing two other portkillers (loss of 10.6 support, whenever that comes, and E10S). Assuming this trajectory continues unchanged we will drop source parity after 45ESR, but there will of course still be updates; besides new features we can now release since we're not worried about maintainability against Mozilla source anymore, we'd still get a fair chance to import later updates to the core that were still in C/C++, and we'd be still a very advanced browser for at least a couple years. We'd be better off than Goanna in Pale Moon, anyway, which is still 24.x-era with various patches.

It had to happen for real sooner or later.

So long, Firefox phones

Fresh from Mozilla's internal revelation they'd like to jettison Thunderbird as a drag on Firefox development (sure to rankle our Tenfourbird builder in the land of the Rising Sun), Mozilla has now announced the end of the Firefox OS smartphone.

I can't say I'm surprised. I liked FxOS as a user, but its application support was dismal (so I could not ditch my Nexus 5, nor could I truly dogfood any Firefox device), and FxOS seemed to only be offered as an option on truly awful hardware. In my case, it was the so-bad-it's-terrible Geeksphone Revulsion Revolution, branded as their developer unit after the whimpering fail of the Peak. True to form, when I actually finally got one, it turned out to be an unmitigated steaming heap and essentially ensured I would never buy a Geeksphone device ever again. Yes, it was that bad. And this was supposed to be their developer device, to get people actually excited about the platform!

That said, I'm sad to see this development (even if I'm not at all shocked), because even though FxOS will live on in some form as an open source project I predict it'll eventually go the benignly neglected way of things like Firefox for webOS (which, having recently acquired an HP Veer for snickers and fighting with endian problems in novacomd, would be really handy about now). That's bad for us in Power Mac land because the improvements to boost Firefox performance on constrained mobile devices also help with our now decade-plus computers. Time will tell if Mozilla decides to kill the entire project as well, not just shipping Firefox phones.

TenFourFoxBox so far has been a huge success. I should publicly mention Mike Hommey's comment in the last blog entry: yes, the true successor to WebRunner is the webapp runtime that Firefox presently comes with, but the webapp runtime doesn't work on 10.4 and needs quite a bit of hacking to do so, and since we weren't using it anyway I could just implement an even lighter chrome and make it even faster. There will be some adjustments to allow people with differently-named executables to work (as well as an override version in case you want to use a specific version of the browser to run your foxboxes), and we need to implement a component for certain sites that try to enumerate navigator.* properties (Chase was the main offender), but otherwise it's been very well received. 1.0 will appear after 38.5.0 and will receive its own website at that time.

Speaking of, I haven't had a lot of time to do much else with 38.5 or the occasional test complaints about the MP3 decoder due to time constraints and finishing my Master's degree, but the MP3 decoder will be enabled and we'll gather some data points to figure out which encoders minimp3 doesn't like (after all, the fact it can play most MP3 files is better than none). There will also be a patch for bug 1181977 to fix the empty Application menu in foxboxes (remember to quit any running foxboxes before you upgrade the browser), and a custodial cleanup after issue 308. Watch for it this weekend for release next week.