Coloured iMacs? We got your coloured iMacs right here

And you don't even need to wait until May. Besides being the best colour Apple ever offered (a tray-loading Strawberry, which is nicer than the current M1 iMac Pink), this iMac G3 also has a 600MHz Sonnet HARMONi in it, so it has a faster CPU and FireWire too. Take that, non-upgradable Apple Silicon. It runs Jaguar with OmniWeb and Crypto Ancienne for web browsing.

Plus, these coloured iMacs can build and run TenFourFox: Chris T proved it on his 400MHz G3. It took 34 hours to compile from source. I always did like slow-cooked meals better.

TenFourFox FPR32 available, plus a two-week reprieve

TenFourFox Feature Parity Release 32 final is now available for testing (downloads, hashes, release notes). This adds an additional entry to the ATSUI font blocklist and completes the outstanding security patches. Assuming no issues, it will go live as the final FPR on or about April 19.

Mozilla is advancing Firefox 89 by two weeks to give them additional time to polish up the UI changes in that version. This will thus put all future release dates ahead by two weeks as well; the next ESR release and the first Security Parity Release parallel with it instead will be scheduled for June 1. Aligning with this, the testing version of FPR32 SPR1 will come out the weekend before June 1 and the final official build of TenFourFox will also move ahead two weeks, from September 7 to September 21. After that you'll have to DIY but fortunately it already looks like people are rising to the challenge of building the browser themselves: I have been pointed to an installer which neatly wraps up all the necessary build prerequisites, provides a guided Automator workflow and won't interfere with any existing installation of MacPorts. I don't have anything to do this with this effort and can't attest to or advise on its use, but it's nice to see it exists, so download it from Macintosh Garden if you want to try it out. Remember, compilation speed on G4 (and, shudder, G3) systems can be substantially slower than on a G5, and especially without multiple CPUs. Given this Quad G5 running full tilt (three cores dedicated to compiling) with a full 16GB of RAM takes about three and a half hours to kick out a single architecture build, you should plan accordingly for longer times on lesser systems.

I have already started clearing issues from Github I don't intend to address. The remaining issues may not necessarily be addressed either, and definitely won't be during the security parity period, but they are considerations for things I might need later. Don't add to this list: I will mark new issues without patches or PRs as invalid. I will also be working on revised documentation for Tenderapp and the main site so people are aware of the forthcoming plan; those changes will be posted sometime this coming week.

TenFourFox FPR32b1 available

I decided not to post this on April Fools Day since a lot of people were hoping the last post was a mistimed April Fools prank, and it wasn't. For one thing, I've never worked that hard on an April Fools joke, even the time when I changed the printer READY messages all over campus to say INSERT FIVE CENTS.

Anyway, the beta for the final TenFourFox Feature Parity Release, FPR32, is now available (downloads, hashes, release notes). This release adds another special preference dialogue for auto reader view, allowing you to automatically jump to reader view for subpages or all pages of domains you enter. I also updated Readability, the underlying Reader View library, to the current tip and also refreshed the ATSUI font blocklist. It will become final on or about April 20 parallel to Firefox 88.

I received lots of kind messages which I have been replying to. Many people appreciated that they could use their hardware for longer, even if they themselves are no longer using their Power Macs, and I even heard about a iMac G4 that is currently a TenFourFox-powered kiosk. I'm willing to bet there are actually a number of these systems hauled out of the closet easily serving such purposes by displaying a ticker or dashboard that can be tweaked to render quickly.

Don't forget, though, that even after September 7 I will still make intermittent updates (primarily security-based) for my own use which will be public and you can use them too. However, as I mentioned, you'll need to build the browser yourself, and since it will only be on a rolling basis (I won't be doing specific versions or tags), you can decide how often you want to update your own local copy. I'll make a note here on the blog when I've done a new batch so that your feedreader can alert you if you aren't watching the Github repository already. The first such batch is a near certainty since it will be me changing the certificate roots to 91ESR.

If you come up with simpler or better build instructions, I'm all ears.

I'm also willing to point people to third-party builds. If you're able to do it and want to take on the task, and don't mind others downloading it, post in the comments. You declare how often you want to do it and which set of systems you want to do it for. The more builders the merrier so that the load can be shared and people can specialize in the systems they most care about.

As a last comment, a few people have asked what it would take to get later versions (52ESR, etc.) to run on Power Macs. Fine, here's a summarized to-do list. None of them are (probably) technically impossible; the real issue is the amount of time required and the ongoing burden needed, plus any unexpected regressions you'd incur. (See also the flap over the sudden Rust requirement for the Python cryptography library, an analogous situation which broke a number of other platforms of similar vintage.)

• Upgrade gcc and validate it.
• Transplant the 32-bit PowerPC JIT to 52's JavaScript. This isn't automatic because you would need to add any new code to the backend required by Ion, and there are some hacks in the source to fix various assumptions SpiderMonkey makes that have to be rechecked and carried forward. There are also some endian fixes. You could get around this by making it interpreter-only, but since much of the browser itself is written in JavaScript, everything will slow down, not just web pages. This task is additionally complicated by our post-45 changes which would need to be undone.
• Transplant the local Cocoa widget changes and merge them with any additional OS support Mozilla added. There are a lot of these patches; some portions were completely rewritten for 10.4 or use old code I dragged along from version to version. A couple people proposed an X11-only version to get around this too. You should be able to do this, and it would probably work, but the code needs some adjustment to deal with the fact it's running on Mac OS X but not with a Cocoa widget system. There are a number of places you would need to manually patch, though this is mostly tedium and not terribly complex.
• The 2D drawing backend changed from CoreGraphics to Skia for technical reasons. Unfortunately, Skia at the time had a lot of problems on big endian and didn't compile properly with 10.4. The former problem might have since been fixed upstream but the latter almost certainly wouldn't have been or would now be worse. You can get around this by using Cairo, but our CG backend was heavily customized, and you will take an additional performance hit on what was probably TenFourFox's worst performing section to begin with since we have no GPU acceleration. It may also be possible to patch the old CG backend back in but you would need to write any additional glue to deal with the higher-level API changes.
• The ICU library required by JavaScript lacked Mozilla build system support for big-endian for a very long time. This was finally fixed in Firefox 80; you would need to backport this.

And then, assuming you want to go post-Firefox 54, there's Rust. Rust is not compatible with 32-bit PowerPC on OS X (it does work on other 32-bit PowerPC operating systems, but those don't run TenFourFox). Besides having to do any adjustments to Rust to emit code compliant with the PowerOpen ABI used by 32-bit PowerPC OS X, you will also have issues with any crates or code that require thread-local storage; OS X didn't support this until 10.7. There may be ways to emulate it and you get to figure those out. On top of that is the need for LLVM: David Fang struggled for years trying to get early versions to work on Tiger, and even MacPorts currently shows llvm-9 on 10.6 as "red", which does not bode well for 10.5 or 10.4. The issue seems to be missing dependencies and you get to figure those out too. I'm just not willing to maintain an entire compiler toolchain and infrastructure on top of maintaining a browser.

If you think I'm wrong about all this, rather than argue with me in the comments, today's your chance to prove it :)

The end of TenFourFox and what I've learned from it

Now that I have your attention.

I've been mulling TenFourFox's future for awhile now in light of certain feature needs that are far bigger than a single primary developer can reasonably embark upon, and recent unexpected changes to my employment, plus other demands on my time, have unfortunately accelerated this decision.

TenFourFox FPR32 will be the last official feature parity release of TenFourFox. (A beta will come out this week, stay tuned.) However, there are still many users of TenFourFox — the update server reports about 2,000 daily checkins on average — and while nothing has ever been owed or promised I also appreciate that many people depend on it, so there will be a formal transition period. After FPR32 is released TenFourFox will drop to security parity and the TenFourFox site will become a placeholder. Security parity means that the browser will only receive security updates plus certain critical fixes (as I define them, such as crash wallpaper, basic adblock and the font blacklist). I will guarantee security and stability patches through and including Firefox 93 (scheduled for September 7) to the best of my ability, which is also the point at which Firefox 78ESR will stop support, and I will continue to produce, generate and announce builds of TenFourFox with those security updates on the regular release schedule with chemspills as required. There will be no planned beta releases after FPR32 but Tenderapp will remain available to triage bugfixes for new changes only.

After that date, for my own use I will still make security patches backported from the new Firefox 91ESR publicly available on Github and possibly add any new features I personally need, but I won't promise these on any particular timeline, I won't make or release any builds for people to download, I won't guarantee any specific feature or fix, I won't guarantee timeliness or functionality, and there will be no more user support of any kind including on Tenderapp. I'll call this "hobby mode," because the browser will be a hobby I purely maintain for myself, with no concessions, no version tags (rolling release only), no beta test period and no regular schedule. You can still use it, but if you want to do so, you will be responsible for building the browser yourself and this gives you a few months to learn how. Also, effective immediately, there will be no further updates to TenFourFoxBox, the QuickTime Enabler, the MP4 Enabler or the TenFourFox Downloader, though you will still be able to download them.

Unless you have a patch or pull request or it's something I care about, if you open an issue on Github it will be immediately closed. Similarly, any currently open issues I don't intend to address will be wound down over the next few weeks. However, this blog and the Github wiki will still remain available indefinitely, including all the articles, and all downloads on SourceForge will remain accessible as well. I'll still post here as updates are available along with my usual occasional topics of relevance to Power Mac users.

Classilla, for its part, is entering "hobby mode" today and I will do no further official public work on it. However, I am releasing the work I've already done on 9.3.4, such as it is, plus support for using Crypto Ancienne for self-hosted TLS 1.2 if you are a Power MachTen user (or running it in Classic or under Mac OS in Rhapsody). You can read more about that on Old VCR, my companion retrocomputing blog.

I'm proud of what we've accomplished. While TenFourFox was first and foremost a browser for me personally, it obviously benefited others. It kept computers largely useable that today are over fifteen years old and many of them even older. In periods of a down economy and a global pandemic this helped people make ends meet and keep using what they had an investment in. One of my favourite reports was from a missionary in Myanmar using a beat-up G4 mini over a dialup modem; I hope he is safe during the present unrest.

I'm also proud of the fair number of TenFourFox features that were successfully backported or completely new. TenFourFox was the first and still one of the few browsers on PowerPC Mac OS X to support TLS 1.3 (or even 1.2), and we are the only such browser with a JavaScript JIT. We also finished a couple features long planned for mainline Firefox but that never made it, such as our AppleScript (and AppleScript-JavaScript bridge) support. Our implementation even lets you manipulate webpages that may not work properly to function usefully. Over the decade TenFourFox has existed we also implemented our own native date and time controls, basic ad block, advanced Reader View (including sticky and automatic features), additional media support (MP3, MP4 and WebP), additional features and syntax to JavaScript, and AltiVec acceleration in whatever various parts of the browser we could. There are also innumerable backported bug fixes throughout major portions of the browser which repair long-standing issues. All of this kept Firefox 45, our optimal platform base, useful for far longer than the sell-by date and made it an important upstream source for other legacy browsers (including, incredibly, OS/2). You can read about the technical differences in more detail.

Many people have contributed to TenFourFox and to the work above, and they're credited in the About window. Some, like Chris T, Ken Cunningham and OlgaTPark, still contribute. I've appreciated everyone's work on the source code, the localizations and their service in the user support forums. They've made the job a little easier. There are not enough thank yous for these good people.

When September rolls around, if you don't want to build the browser yourself it is possible some downstream builders like Olga may continue backports. I don't speak for them and I can't make promises on their behalf. Olga's builds run on 10.4, 10.5 and 10.6. If you choose to make your own builds and release them to users, please use a different name for your builds than TenFourFox so that I don't get bothered for support for your work (Olga has a particular arrangement with me but I don't intend to repeat it for others).

You might also consider another browser. On PowerPC 10.5 your best alternative is Leopard WebKit. It has not received recent updates but many of you use it already. I don't maintain or work on LWK, but there is some TenFourFox code in it, and Tobias has contributed to TenFourFox as well. If you don't want to use Safari specifically, LWK can be relinked against most WebKit shells including Stainless and Roccat.

If you are using TenFourFox on 10.6, you could try using Firefox Legacy, which is based on Firefox 52. It hasn't been updated in about a year but it does have a more recent platform base than official Firefox for 10.6 or TenFourFox.

However, if you are using TenFourFox on 10.4 (PowerPC or Intel), I don't have any alternative suggestions for you. I am not aware of any other vaguely modern browser that supports Tiger. Although some users have tried TenFourKit, it does not support TLS 1.1 or 1.2 (only Opera 10.63 does), and OmniWeb, Camino, Firefox 3.6 and the briefly available Tor Browser for PowerPC are now too old to recommend for any reasonable current use.

So, that's the how. Here's the why and what. I have a fairly firm rule that I don't maintain software I don't personally use. The reason for that is mostly time, since I don't have enough spare cycles to work on stuff that doesn't benefit me personally, but it's also quality: I can't maintain a quality product if I don't dogfood it myself. And my G5 has not been my daily driver for a good couple years; my daily driver is the Raptor Talos II. I do use the G5 but for certain specific purposes and not on a regular daily basis.

Additionally, I'm tired. It's long evenings coding to begin with, but actual development time is only the start of it. It's also tying up the G5 for hours to chug out the four architecture builds and debug (at least) twice a release cycle, replying to bug reports, scanning Bugzilla, reading the changelogs for security updates and keeping up with new web features in my shrinking spare time after doing the 40+-hour a week job I actually got paid for. Time, I might add, which is taken away from my other hobbies and my personal relaxation, and time which I would not need to spend if I did this purely as a hobby and never released any of it. Now that Firefox is on a four-week release schedule, it's just more than I feel I can continue to commit to and I'm neglecting the work I need to do on the system that I really do use every day.

We're running on fumes technologically as well. Besides various layout and DOM features we don't support well like CSS grid, there are large JavaScript updates we'll increasingly need which are formidably complex tasks. The biggest is async and await support which landed in Firefox 52, and which many sites now expect to run at all. However, at the time it required substantial changes to both JavaScript and the runtime environment and had lots of regressions and bugs to pick up. We have some minimal syntactic support for the feature but it covers only the simplest of use cases incompletely. There are also front end changes required to deal with certain minifiers (more about this in a moment) but they can all be traced back to a monstrous 2.5MB commit which is impossible to split up piecemeal. We could try to port 52ESR as a whole, but we would potentially suffer some significant regressions in the process, and because there is no Rust support for 32-bit PowerPC on OS X we couldn't build anything past Firefox 54 anyway. All it does is just get us that much closer to an impenetrable dead end. It pains me to say so, but it's just not worth it, especially if I, the browser's only official beneficiary, am rarely using it personally these days. It's best to hang it up here while the browser still works for most practical purposes and people can figure out their next move, rather than vainly struggling on with token changes until the core is totally useless.

Here is what I have learned working on TenFourFox and, for that matter, Classilla.

Writing and maintaining a browser engine is fricking hard and everything moves far too quickly for a single developer now. However, JavaScript is what probably killed TenFourFox quickest. For better or for worse, web browsers' primary role is no longer to view documents; it is to view applications that, by sheer coincidence, sometimes resemble documents. You can make workarounds to gracefully degrade where we have missing HTML or DOM features, but JavaScript is pretty much run or don't, and more and more sites just plain collapse if any portion of it doesn't. Nowadays front ends have become impossible to debug by outsiders and the liberties taken by JavaScript minifiers are demonstrably not portable. No one cares because it works okay on the subset of browsers they want to support, but someone bringing up the rear like we are has no chance because you can't look at the source map and no one on the dev side has interest in or time for helping out the little guy. Making test cases from minified JavaScript is an exercise in untangling spaghetti that has welded itself together with superglue all over your chest hair, worsened by the fact that stepping through JavaScript on geriatic hardware with a million event handlers like waiting mousetraps is absolute agony. With that in mind, who's surprised there are fewer and fewer minority browser engines? Are you shocked that attempts like NetSurf, despite its best intentions and my undying affection for it, are really just toys if they lack full script runtimes? Trying and failing to keep up with the scripting treadmill is what makes them infeasible to use. If you're a front-end engineer and you throw in a dependency on Sexy Framework just because you can, don't complain when you only have a minority of browser choices because you're a big part of the problem.

Infrastructure is at least as important as the software itself. A popular product incurs actual monetary costs to service it. It costs me about US$600 a month, on average, to run my home data center where Floodgap sits (about ten feet away from this chair) between network, electricity and cooling costs. TenFourFox is probably about half its traffic, so offloading what we can really reduces the financial burden, along with the trivial amount of ad revenue which basically only pays for the domain names. Tenderapp for user support, SourceForge for binary hosting, Github for project management and Blogger for bloviating are all free, along with Google Code where we originally started, which helped a great deal in making the project more sustainable for me personally even if ultimately I was shifting those ongoing costs to someone else. However, the biggest investment is time: trying to stick to a regular schedule when the ground is shifting under your feet is a big chunk out of my off hours, and given that my regular profession is highly specialized and has little to do with computing, you can't really pay me enough to dedicate my daily existence to TenFourFox or any other open-source project because I just don't scale. (We never accepted donations anyway, largely to avoid people thinking they were "buying" something.) I know some people make their entire living from free open source projects. I think those people are exceptions and noteworthy precisely because of their rarity. Most open source projects, even ones with large userbases, are black holes ultimately and always will be.

Gecko has a lot of technical baggage, but it is improving by leaps and bounds, and it is supported by an organization that has the Internet's best interests at heart. I have had an active Bugzilla account since 2004 and over those 16+ years I doubt I would have gotten the level of assistance or cooperation from anyone else that I've received from Mozilla employees and other volunteers. This is not to say that Mozilla (both MoFo and MoCo) has not made their blunders, or that I have agreed personally with everything they've done, and with respect to sustainability MoCo's revenues in particular are insufficiently diversified (speaking of black holes). But given my experience with other Mozillians and our shared values I would rather trust Mozilla any day with privacy and Web stewardship than, say, Apple, who understandably are only interested in what sells iDevices, and Google, who understandably are only interested in what improves the value proposition of their advertising platforms. And because Chrome and Chromium effectively represent the vast majority of desktop market share, Google can unilaterally drive standards and force everyone to follow. Monopolies, even natural ones, may be efficient but that doesn't make them benign. I'll always be a Firefox user for that reason and I still intend to continue contributing code.

Now for the mildly controversial part of this post and the one that will make a few people mad, but this is the end of TenFourFox, and a post-mortem must be comprehensive. For this reason I've chosen to disable comments on this entry. Here is what you should have learned from TenFourFox (much the same thing users should have learned from any open-source project where the maintainer eventually concluded it was more trouble than it was worth).

If you aren't paying for the software, then please don't be a jerk. There is a human at the other end of those complaints and unless you have a support contract, that person owes you exactly nothing. Whining is exhausting to read and "doesn't work" reports are unavoidably depressing, disparaging or jokey comments are unkind, and making reports nastier or more insistent doesn't make your request more important. This is true whether or not your request is reasonable or achievable, but it's certainly more so when it isn't.

As kindly as I can put it, not all bug reports are welcome. Many are legitimately helpful and improve the quality of the browser, and I did appreciate the majority of the reports I got, but even helpful bug reports objectively mean more work for me though it was work I usually didn't mind doing. Unfortunately, the ones that are unhelpful are at best annoying (and at worst incredibly frustrating) because they mean unhappy people with problems that may never be solvable.

The bug reports I liked least were the ones that complained about some pervasive, completely disabling flaw permeating the entire browser from top to bottom. Invariably this was that the browser "was slow," but startup crashes were probably a distant second place. The bug report would inevitably add something along the lines of this should be obvious, or talk about the symptom(s) as if everyone must be experiencing it (them).

I'm not doubting what people say they're seeing. But you should also consider that asserting the software has such a grave fault effectively alleges I either don't use the software or care about it, or I would have noticed. Most of the time my reply was to point out that my reply was being made in the browser itself, and to point out that we had regular beta phases where the alleged issue had not surfaced, so no, it must not be that pervasive, and let's figure out why your computer behaves that way. As far as the browser being slow, well, that's part personal expectation and part technical differences. TenFourFox would regularly win benchmarks against other Power Mac browsers because its JavaScript JIT would stomp everything else, but its older Mozilla branch has weaker pixelpushing and DOM that is demonstrably slower than WebKit, and no Power Mac browser is going to approach the performance you would get on an Intel Mac with any browser. Some of this is legitimate criticism, but overall if that's what you're expecting, TenFourFox will disappoint you. And it certainly did disappoint some people, who felt completely empowered to ignore all that context and say so.

Here is another unwelcome bug report, sometimes part of those same reports: "Version X+1 does something bad that Version X didn't, so I went back to Version X (or I've switched to another browser). Please let me know when it's fixed."

As a practical consideration, if you have such a serious issue where you can't use the browser for your desired purpose then I guess you do what you gotta do. But consider you may also be saying that you don't care about solving the problem. Part of it is, like the last report, making the sometimes incorrect assumption that everyone else must be seeing what you're seeing. But the other part is because you've already reverted to the previous release, you don't have any actual investment in the problem being solved. If it actually is a problem that can be fixed, and I do fix it, you're using the previous version and may or may not be in a position to test it. But if it's actually a problem I can't observe, then it won't get fixed assuming it actually does exist, because I don't see that problem on Version X+1 myself and the person who can see it, i.e., you, has bailed out. If you want me to fix it, especially if you are unwilling or unable to fix it yourself, then you need to stick with it like I'm sticking with it.

What should you do? Phrase it better. Post your reports with the attitude that you are just one user, using free software, from the humility of your own personal experience on your own system. Make it clear you don't expect anything from the report, you are grateful the software exists, you intend to keep using it and this is your small way of giving back. Say this in words because I can't see your face or hear your voice. Write "thank you" and mean it. Acknowledge the costs in time and money to bring it to you. Tell me what's good about it and what you use it for. That's how you create a relationship where I can see you as a person and not a demand request, and where you can see me as a maintainer and not a vending machine. Value my work so that I can value your insights into it. Politeness, courtesy and understanding didn't go out the window just because we're interacting through a computer screen.

Goodness knows I haven't been perfect and I've lost my temper at times with people (largely justifiably, I think, but still). All of us are only human. But today, looking back on everything that's happened, I'm still proud of TenFourFox and I'm still glad I started working on it over 10 years ago. Here's the first functional build of Firefox 4.0b7pre on Tiger (what became the first beta of TenFourFox), dated October 15, 2010:

This was back when Mozilla was sending thank-you cards to Firefox 4 beta testers:

TenFourFox survived a lot of times when I thought it was finished for one technical reason or another, and it's still good enough for the couple thousand people who use it every day and the few thousand more who use it occasionally. It kept a lot of perfectly good hardware out of landfills. And most of all, it got me years more out of my own Quad G5 and iBook G4 and it still works well enough for the times I do still need it. Would I embark upon it again, knowing everything I know now and all the work and sweat that went into it? Heck yeah. In a heartbeat.

It was worth it.

TenFourFox FPR31 available

TenFourFox Feature Parity Release 31 final is now available for testing (downloads, hashes, release notes). There are no additional changes from the beta except for outstanding security patches. Locale langpacks will accompany this release and should be available simultaneously on or about Monday or Tuesday (March 22 or 23) parallel to mainline Firefox.

TenFourFox FPR31b1 available (now with site-specific user agent UI and Auto Reader View)

TenFourFox Feature Parity Release 31 beta 1 is now available (downloads, hashes, release notes). I didn't get everything done here that I wanted to, though thanks to Chris T I do have a reproducing local test version of the infamous issue 621; at least I am able now to see that it's clearly a problem in the JavaScript parser generating something incorrectly, but I'm still not able to tell where the specific deficiency lies.

However, there's still new stuff in this release. Olga T Park contributed a backport from later Firefox versions to fix saving passwords in private browsing, and I also finished fully exposing support for site specific user agents. This was quietly reimplemented in FPR17 for interested users, but now that it's getting more and more necessary on more and more sites, I have made the feature a visible and supported part of the browser interface. Instead of having to enter sites and strings manually into about:config, though you still can, you can now go to the TenFourFox preference pane,

and click the new "Site Specific" button under User Agent. A new dialogue box will open.

Site-specific user agents in use appear in the bottom half of the window with domain and user agent strings. You can enter anything you want for a user agent string, as shown, or you can pick a pre-defined one to fill the box from the dropdown (the same ones you would be offered for the global user agent option, which remains supported as well). In this example I've chosen a random "what's my user agent" domain and assigned the Classilla string to it. We click Save Changes and try it out:

Ta-daa. As before, having site-specific user agent strings does slightly slow the browser down, though most of the penalty is paid on the first and not so much on additional strings you enter. Our implementation has no penalty if you have no site-specific user agents loaded and this remains the default. For sites that are unspecified, obviously the global user agent option still applies. If you have a user-agent add-on already installed, you can still use it, but it may have interactions if you try to use this feature at the same time and you're on your own if you do.

I was also planning to do a Reader View update for this release, which will need a user interface of its own, but every new UI feature requires additional locale strings and I wanted to give our localizers (led by Chris) a chance to catch up on the new strings in time for the final release on March 22. However, I do have a not-yet-exposed feature's plumbing done, which is another enhancement to Reader View: auto Reader View.

Auto Reader View is different from sticky Reader View, which has been the default since FPR27. Sticky Reader View means that when you go into Reader View, links you click on also load in Reader View, until you quit it by clicking one of the exit buttons. Auto Reader View, however, allows you to tell the browser to automatically open pages from a domain in Reader View as soon as you click on any link to that domain from any page, in Reader View or not. Since front pages may not work as well, you can specify to do this just for "subpages" or for all pages.

An example is the Los Angeles Times, which is more or less my semi-local newspaper here in Southern California. Its article pages have a lot of irritating popup divs, so go into about:config, create a new string preference called tenfourfox.reader.auto.www.latimes.com and set it to the single letter s (for subpages; for all pages, use y for, um, "yes"). Now, visit the L.A. Times front page. It renders in the normal browser view, but if you click on any article, it immediately shifts to Reader View. Click the back button and you're back on the front page. If you decide you do want to see the article as intended, just click the Reader View icon in the address bar as usual, and the article will render in "full" form; links to subpages you click on from there will go back to Reader View.

As I've said many times, I think Reader View is an important way of making sites render faster and more usefully, especially on G3 and low-end G4 systems. It also cuts out a lot of crap, meaning it's back to only the columnists annoying me in the L.A. Times and not the popups. For FPR32 I will be updating the internal Reader View to the current version of Readability.js, adding a preference pane UI similar to site-specific user agents, and maybe also adding the current Firefox feature allowing you to adjust the gutter margins wider or narrower. But for now you can experiment with the feature and let me know how functional or useful it is to you. FPR31 final comes out on or around March 22, parallel with Firefox 78.9 and 87.

TenFourFox FPR30 SPR2 available

TenFourFox Feature Parity Release "30.2" (SPR 2) is now available for testing (downloads, hashes, release notes). The reason this is another security-only release is because of my work schedule and also I spent a lot of time spinning my wheels on issue 621, which is the highest priority JavaScript concern because it is an outright crash. The hope was that I could recreate one of the Apple discussion pages locally and mess with it and maybe understand what is unsettling the parser, but even though I thought I had all the components, it still won't load or reproduce in a controlled environment. I've spent too much time on it and even if I could do more diagnostic analysis I still don't know if I can do anything better than "not crash" (and in SPR2 is a better "don't crash" fix, just one that doesn't restore any functionality). Still, if you are desperate to see this fixed, see if you can create a completely local Apple discussions page or clump of files that reliably crashes the browser. If you do this, either attach the archive to the Github issue or open a Tenderapp ticket and let's have a look. No promises, but if the community wants this fixed, the community will need to do some work on it.

In the meantime, I want to get back to devising a settings tab to allow the browser to automatically pick appropriate user agents and/or start reader mode by domain so that sites that are expensive or may not work with TenFourFox's older hacked-up Firefox 45 base can automatically select a fallback. Our systems are only getting slower compared to all the crap modern sites are adding, after all. I still need to do some plumbing work on it, so the fully-fledged feature is not likely to be in FPR31, but I do intend to have some more pieces of the plumbing documented so that you can at least mess with that. The user-agent selector will be based on the existing functionality that was restored in FPR17.

Assuming no major issues, FPR30 SPR2 goes live Monday evening Pacific as usual.