TenFourFox FPR2b1 available (plus: come to VCF!)

TenFourFox Feature Parity Release 2 beta 1 is now available (downloads, hashes, release notes). Besides various and sundry additional optimizations once again shamelessly backported from the Quantum project, this release includes the accelerated AltiVec string matching routine which I will be also hooking up to other parts of the browser in future releases, and reworks the font blacklist so that Apple sites work again (and more efficiently). Release is planned for August 8.

With this beta you will notice I've made a new build available - a true "Debug" build. Since currently we really only have comprehensive test coverage for JavaScript, this gives people a chance to help debug other browser issues without having to build the entire application themselves. I intend to only issue these for beta releases since the idea is to have as few changes as possible between the beta and the release version. Please take heed of this warning: the Debug version is not for mere mortals. Because it has a full symbol table, it could cause your system's crash dump facility to hang if it bombs and you weren't running it within the TenFourFox debugger (and if that happens, you'll have to kill the crash dump or it will peg your CPU; I actually hacked /usr/libexec/crashdump to not run if I've touched /tmp/no_crashdump as a flag). In addition, the debug build is much slower, runs a lot of sanity checking code and generates copious logging output. It is not optimized for any processor and has no AltiVec code, so it will run (badly) on any compatible Power Mac. Please refer to the developer instructions and understand what you're doing before you run it, and if you do run it, I strongly suggest creating a separate profile specifically for debugging if you intend to work with it often. The debugging versions will not be offered from the main TenFourFox page so clueless folks don't grab it by accident.

Next up, FPR3 will have some additional optimizations and performance improvements too, but will be focused instead more towards supporting new features again: in addition to some minor compatibility tweaks, I would like to get enough of our CSS grid support working to be credible and do further improvements to our JavaScript ES6 implementation. More on that a little later.

A schedule note: I'll be demonstrating the Apple Network Server 500 (the original floodgap.com) at this year's Vintage Computer Festival West August 5 and 6 at the Computer History Museum in Mountain View, CA (last year's exhibit was good fun). The ANS (codenamed "Shiner" after a local brand of beer in Texas, where it was developed) was arguably Apple's first true-UNIX server (A/UX notwithstanding), almost certainly the biggest computer they've ever made, and the last general purpose computer they built that wasn't a Mac. I ran mine almost non-stop from 1998 to 2012 as my main server (14 years), and it came back briefly in 2014 when the POWER6 currently running Floodgap blew its mainboard. I'll have it set up so you can play with it, plus an actual prototype Shiner for display and a couple (haven't decided?) PowerBook clients to demonstrate its unusual software powers. Be there or be less nerdy than I am.

Oh, and at last, Flash is dead (by 2020). But it was dead to us in Power Mac-land a long time ago. Finally the rest of the world catches up.

Do you work for Facebook? Do you like old Power Macs? Help a brother out.

Are you a front-end engineer for Facebook? Are you sympathetic to us struggling masses trying to keep our Power Macs out of the landfill? Do you, too, secretly agree that the iMac G4 looks far better than any of the crap Tim Cook and friends churn out now?

If so, give your TenFourFox users a little hand. Yes, I will preface this by saying I do not use, nor (candidly) particularly like, Facebook, but lots of TenFourFox users do and I've reached the limit of my debugging ability against the minified front end of Facebook.

We have an issue with our custom keyboard handling code with users pressing Delete repeatedly: it not only doesn't delete anything but the first character, but actually inserts repeated 0x08 bytes (i.e., the ASCII value for Delete). Everything else seems to work. Obviously this is our bug, because regular Firefox (including Firefox ESR 45, on which we are ultimately based) doesn't do this, but I can't determine what DOM fields our keydown events aren't correctly providing to Facebook's keydown handler because the code is minified to hell. And debugging minified event handlers even with my Quad G5 cranked to ludicrous is not a good time. No other site seems to do this, so I don't have something smaller to test against either.

So, if you're a Mac retronerd and also a Facebook front-end engineer, does this ring a bell to you? If it doesn't, is there at least a non-minified version I can test against? I sent an E-mail to browsers at fb but got no reply, so I'm asking publicly and begging for your mercy so we can keep our otherwise perfectly good Macs serviceable and running. And for some people, "serviceable and running" means Facebook. So I won't judge. Honest.

Jokes aside, I'd really appreciate any of your insights and time. You can drop a line to classilla at floodgap dawt com if you have a suggestion (or better yet the answer).

We're delayed on FPR2 because I'm trying to track down a regression one of the security backports caused during shutdown when network connections are pending. However, this blog post is being typed in it, so it's otherwise working and I'm still shooting for the official beta next week.

Talos take II

First, ob-TenFourFox stuff. As the wonderful Dutch progressive rock band Focus plays "Sylvia" in the CD player, I'm typing this in a partially patched up build of FPR2, which has a number of further optimizations including an AltiVec-accelerated memchr() implementation (this improves JavaScript regex matching by about 15 percent, but also beefs up some other parts of the browser which call the same library function) and some additional performance backports ripped off from Mozilla's Quantum project. This version also has a re-tuned G5 build with some tweaked compiler settings to better match the 970 cache line size, picking up some small but measurable improvements on Acid3 and other tests. Even the G3 gets some love: while it obviously can't use the AltiVec memchr(), it now uses a better unrolled character matcher instead and picks up a few percentage points that way. I hope to finish the security patch work by this weekend, though I am still annoyed to note I cannot figure out what's up with issue 72.

Many of you will remember the Raptor Talos, an attempt to bring a big beefy POWER8 to the desktop that sadly did not meet its crowdsource funding goal. Well, I'm gratified to note that Raptor is trying again with a smaller scale system but a bigger CPU: the POWER9-based Talos II. You want a Power-based, free and open non-x86 alternative that can kick Intel's @$$? Then you can get one of these and not have to give up performance or processing (eheheh) power. The systems will use the "scale-out" dual socket POWER9 with DDR4 RAM and while the number of maximum supported cores on Talos II has not yet been announced, I'll just say that POWER9 systems can go up to 24 cores and we'll leave it at that. With five PCIe slots, you can stick a couple cool video cards in there too and rock out. It runs ppc64le Linux, just like the original Talos.

I'm not (just) interested in a thoroughly modern RISC workstation, though: I said before I wanted Talos to be the best way to move forward from the Power Mac, and I mean it. I'm working on tuning up Firefox for POWER8 with optimizations that should carry to POWER9, and once that builds, beefing the browser up further with a new 64-bit Power ISA JavaScript JIT with what we've learned from TenFourFox's 32-bit implementation. I'd also like to optimize QEMU for the purpose of being able to still run instances of OS 9 and PowerPC OS X in emulation at as high performance on the Talos II as possible so you can bring along your legacy applications and software. When pre-orders open up in August -- yes, next month! -- I'm going to be there with my hard-earned pennies and you'll hear about my experiences with it here first.

But don't worry: the G5 is still going to be under my desk for awhile even after the Talos II arrives, and there's still going to be improvements to TenFourFox for the foreseeable future because I'll still be using it personally for the foreseeable future. PowerPC forever.

OverbiteFF will cease functioning with Firefox 56 (we need WebExtension sockets)

For those unfamiliar, TenFourFox and Classilla aren't my only Mozilla-related projects; the other one I've maintained for some time is OverbiteFF, which adds Gopher support back to Firefox as a first-class citizen. It does so by implementing nsIChannel and nsIProtocolHandler objects which speak Gopher and allows everything to "just work" like any other URL. Because of how the protocol works, the add-on also enables whois and finger protocol support with a little bit of URL gyration, and to this day there is a small but dedicated userbase.

As of Firefox 56, it is my understanding that non-multiprocess-compatible extensions will no longer be supported, which is currently in nightly. Even if I were able to make OverbiteFF MP compatible, however (there were some technical hurdles to be overcome when I tried), it is highly dependent on XPCOM and Firefox 57 will be the end of that. As a result, OverbiteFF in its current form will cease functioning with Firefox 56. It will, of course, continue to work with TenFourFox and Firefox 52ESR, so I would recommend switching to 52ESR as a stopgap if you need to run XPCOM-dependent extensions like this one and are not lucky enough to have a Power Mac. For Firefox Android users, Overbite Android works wonderfully as an external application and Firefox Android will hand Gopher URLs to it; I use my own work on a Google Pixel XL with Android 7.1.2.

Unfortunately, there is no way to make OverbiteFF compatible with WebExtensions, even with reduced functionality: no one has implemented TCP socket access for extensions, and the protocol handler support is not only incomplete but actually intentionally excluded the Gopher protocol in URLs (so I can't even implement it like the old Overbite Chrome, which rewrote requests for any of the available Gopher->HTTP gateways). I'd submit a patch to whitelist gopher for the latter but there's been no motion on dealing with the standards clash that caused it, and there's not even an API description for WX socket support, let alone code written to implement it.

Clearly OverbiteFF is hardly alone among extensions in these requirements (for example, uProxy, Chatzilla, FireFTP and FireSSH will all stop working too), but I'm particularly bitter about this because its genesis came from the protracted end of Gopher support in Firefox 4. The tl;dr from that bug was, paraphrased straight from Mountain View, it's being yanked and you can't stop it, so learn XPCOM and write an add-on and maintain the feature yourself. Well, I did, it worked, people used it, and now it's going to stop working and unless motion occurs on these APIs I won't be able to make it work ever again in the future. You can post all the happy talk about how wonderful the end of XPCOM add-ons is for paying back Gecko's technical debt and I'm not going to dispute that, but that doesn't mean it doesn't suck. On the eve of WebExtensions' full takeover it feels like yet another broken promise.

Please, let's see motion on these and related APIs soon.

TenFourFox FPR1 available

TenFourFox Feature Parity Release 1 is available for testing (downloads, hashes, release notes). There are no major changes from the beta except for a couple minor efficiency updates and a font blacklist update, and all remaining applicable security issues have been backported as well.

Chris T reported that old issue 72 (a/k/a bug 641597) has resurfaced in FPR1. Most likely this bug was never actually fixed, just wallpapered over by something or other, and the efficiency improvements in FPR1 have made it easier to trigger again. That said, it has only ever manifested on certain 10.5 systems; it has never been reproduced on 10.4 by anyone, and I can't reproduce it myself on my own 10.5 DLSD PowerBook G4. For that reason I'm proceeding with the release as intended but if your system is affected, please post your steps to replicate and we'll compare them with Chris' (especially if you have a 10.4 system, since that will be much easier for me to personally debug). Please also note any haxies or system extensions as the issue can be replicated on a clean profile, meaning addons or weird settings don't appear to be a factor. If we find a fix and enough people are bitten, it should be possible to spin a point release.

The plan is for a Tuesday/Wednesday release ahead of schedule, so advise if there are any new showstoppers.

Feature Parity Release Finally Preview Ready For Persistent Readers

This blog has been pretty quiet because I've been pretty busy, but now you get to play with the first TenFourFox Feature Parity Release beta (downloads, release notes, hashes).

Internally, TenFourFox FPR1 is versioned as 45.10.0 to maintain add-on compatibility (but read on for an important caveat), and all FPRs will be based on our fork of Firefox ESR 45, though the About box and the user agent show the current parity release level. This release primarily concentrated on performance and I liberally stole backported changes from Mozilla's Quantum Flow Engineering project as many of its changes touch relatively old code, so it's still applicable to us, and if the issues they're fixing are minor but noticeable on modern systems they would certainly be more noteworthy on our older machines. Most of the speed changes occur in the user interface, layout and DOM; there are some minor improvements to JavaScript as well, but that wasn't the major focus for this iteration (another big JavaScript JIT performance initiative is planned for FPR2 or FPR3, though). The overall functionality of the UI hasn't changed, however, so it should still work the way it did before. Not every enhancement I wanted to make has made it to FPR1, including one nice speedup that unfortunately also made the browser unstable, so there will be more to come in future versions. The speed difference isn't dramatic but I hope you'll agree it's a positive improvement.

Also new in FPR1 is official support for Brotli, a more efficient compression mechanism than the gzip and DEFLATE methods we currently support. Mozilla disabled this in 45 due to bugs; I secretly backported the version from ESR52 with the bugs fixed and made the (small number of) necessary changes to the browser for 45.9, which this version now enables by default. It only operates over HTTPS and on those sites that support it, but this number is expected to grow as Chrome, Firefox, Microsoft Edge and Opera all accept it.

In addition, this release introduces several new ECMAScript 6 (ES6) features to our JavaScript implementation, including Unicode regexes and block function scoping, and the ES7 exponentiation operator. Websites are already beginning to use these features, so it was essential we implement them (eventually I would like full ES6 compatibility and as much ES7 compatibility as we can reasonably achieve), but it is possible some poorly coded add-ons may barf with these changes. The syntactic changes can't really be reversed or preffed off, and add-on support in TenFourFox was always "best effort" anyhow, but please do report any changes in site and add-on compatibility that you notice between 45.9 and FPR1 so I can evaluate them. In the next couple updates I will add more ES6/ES7 features as well as some additional HTML5 and CSS3 functions that sites are beginning to adopt in keeping with the whole "feature parity" thing.

I've also been backporting relevant security patches from 52ESR to 45ESR, and our tree is now able to accept updated TLS root certificates, pinned certificates and HSTS data from 52ESR more or less directly. Eventually I still plan to update to the NSS library in 52ESR so that we can get additional cipher and encryption support, but this suffices for now. Please note that, as threatened promised, all SHA-1-only certificates are now untrusted. Most of the ESR security patches to date have been applied to the version you will be trying out except for a couple of very large changesets that need a bit more evaluation. We will be at full security parity for all known issues by the date of release.

Speaking of release date, FPR1 will be a bit delayed as I will be taking a brief vacation and I won't be at my G5 for a little while. Mozilla's release schedule has 54/52.2 coming out on June 13, which won't give me enough time to complete my work and do internal testing (hey, I'm entitled to some time off), so my current plan is to release FPR1 on or before June 27 and then catch up for FPR2 with the release of 55/52.3 on August 8. It is possible that I may delay future FPR releases until a couple days after the main ESR is released for testing and backporting reasons, but let's see how close I can adhere to the schedule still.

For builders, now that our Github is off and running, there's no need to continue distributing changesets; future releases at SourceForge will have just a placeholder instead of a zip file for source. Instead, please kindly refer to the updated build instructions.

Oh, one more thing: it looks like someone is working on an Intel version of TenFourFox again (compatible with at least 10.6 and possibly even 10.5). I won't say whom because it may be some time before anything is available, and as I've always said, this is not a release I can personally maintain even though I am happy to support and advise someone willing to, but their early work looks promising and they appear to have sufficient expertise to make it happen. Once their changes make it back into the TenFourFox github we can consider it "officially a thing." Meanwhile, although the development is occurring more or less in the open and you can probably find it without much effort, please don't pester me or them about it since it hasn't gotten off the ground yet.

Post observations in the comments and feel free to star or watch the Github repo for updates.

The аррӏе bites back

I've received a number of inquiries about whether TenFourFox will follow the same (essentially wontfix) approach of Firefox for dealing with those international domain names that happen to be whole-script homographs. The matter was forced recently by one enterprising sort who created just this sort of double using Cyrillic characters for https://www.аррӏе.com/, which depending on your font and your system setup, may look identical to https://www.apple.com/ (the site is a proof of concept only).

The circulating advice is to force all IDNs to be displayed in punycode by setting network.IDN_show_punycode to true. This is probably acceptable for most of our users (the vast majority of TenFourFox users operate with a Latin character set), but I agree with Gerv's concern in that Bugzilla entry that doing so disadvantages all other writing systems that are not Latin, so I don't feel this should be the default. That said, I also find the current situation unacceptable and doing nothing, or worse relying on DNS registrars who so far don't really care about anything but getting your money, similarly so. While the number of domains that could be spoofed in this fashion is probably small, it is certainly greater than one, and don't forget that they let the proof-of-concept author register his spoof!

Meanwhile, I'm not sure what the solution right now should be other than "not nothing." Virtually any approach, including the one Google Chrome has decided to take, will disadvantage non-Latin scripts (and the Chrome approach has its own deficiencies and is not IMHO a complete solution to the problem, nor was it designed to be). It would be optimal to adopt whatever solution Firefox eventually decides upon for consistency if they do so, but this is not an issue I'd like to sit on indefinitely. If you use a Latin character set as your default language, and/or you don't care if all domains will appear in either ASCII or punycode, then go ahead and set that pref above; if you don't, or consider this inappropriate, stay tuned. I'm thinking about this in issue 384.

By the way, TenFourFox "FPR0" has been successfully uploaded to Github. Build instructions to follow and the first FPR1 beta should be out in about two to three weeks. I'm also cogitating over a blog post discussing not only us but other Gecko forks (SeaMonkey, Pale Moon, etc.) which for a variety of reasons don't want to follow Mozilla into the unclear misty haze of a post-XUL world. To a first approximation our reasons are generally technical and theirs are primarily philosophical, but we both end up doing some of the same work and we should talk about that as an ecosystem. More later.