Thursday, November 21, 2019

TenFourFox FPR17b1 available

TenFourFox Feature Parity Release 17 beta 1 is now available (downloads, hashes, release notes). SourceForge seems to have fixed whatever was making TenFourFox barf on its end which now might actually be an issue over key exchange. For a variety of reasons, but most importantly backwards compatibility, my preference has been to patch up the NSS security library in TenFourFox to support new crypto and ciphers rather than just drop in a later version. We will see if the issue recurs.

This release fixes the "infinite loop" issue on Github with a trivial "hack" mitigation. This mitigation makes JavaScript slightly faster as a side-effect but it's because it relaxes some syntax constraints in the runtime, so I don't consider this a win really. It also gets rid of some debug-specific functions that are web-observable and clashed on a few pages, an error Firefox corrected some time ago but missed my notice. Additionally, since 68ESR newly adds the ability to generate and click on links without embedding them in the DOM, I backported that patch so that we can do that now too (a 4-year-old bug only recently addressed in Firefox 70). Apparently this functionality is required for certain sites' download features and evidently this was important enough to merit putting in an extended support release, so we will follow suit.

I also did an update to cookie security, with more to come, and cleared my backlog of some old performance patches I had been meaning to backport. The most important of these substantially reduces the amount of junk strings JavaScript has hanging around, which in turn reduces memory pressure (important on our 32-bit systems) and garbage collection frequency. Another enables a fast path for layout frames with no properties so we don't have to check the hash tables as frequently.

By user request, this version of TenFourFox also restores the old general.useragent.override.* site-specific override pref feature. This was removed in bug 896114 for performance reasons and we certainly don't need anything that makes the browser any slower, so instead of just turning it back on I also took the incomplete patch in that bug as well and fixed and finished it. This means, in the default state with no site-specific overrides, there is no penalty. This is the only officially supported state. I do not have any plans to expose this feature to the UI because I think it will be troublesome to manage and the impact on loading can be up to 9-10%, so if you choose to use this, you do so at your own risk. I've intentionally declined to mention it in the release notes or to explain any further how this works since only the people who already know what it does and how it operates and most importantly why they need it should be using it. For everyone else, the only official support for changing the user agent remains the global selector in the TenFourFox preference pane (which I might add now allows you to select Firefox 68 if needed). Note that if you change the global setting and have site-specific overrides at the same time, the browser's behaviour becomes "officially undefined." Don't file any bug reports on that, please.

Finally, this release also updates the ATSUI font blacklist and basic adblock database, and has the usual security, certificate, pin, HSTS and TLD updates. Assuming no issues, it will go live on December 2nd or thereabouts.

For FPR18, one thing I would like to improve further is the built-in Reader mode to at least get it more consistent with current Firefox releases. Since layout is rapidly approaching its maximum evolution (as determined by the codebase, the level of work required and my rapidly dissipating free time), the Reader mode is probably the best means for dealing with the (fortunately relatively small) number of sites right now that lay out problematically. There are some other backlogged minor changes I would like to consider for that release as well. However, FPR18 will be parallel with the first of the 4-week cadence Firefox releases and as I have mentioned before I need to consider how sustainable that is with my other workloads, especially as most of the low-hanging fruit has long since been picked.


  1. Many thanks for adding the user agent override - testing on my Powerbook DLSD I can happily report I've not seen any performance issues by having this feature implemented, in fact, FPR17b1 appears fractionally faster on the page loading timings I've just done.
    On my portables I like TFF to cruise with the lowest specified user agent possible to save resources but inevitably that breaks a lot of sites. Now it's best of both worlds, automatically switching user agents on the fly.

    1. The fractional improvement may be due to the other optimizations in this release. I still officially won't surface it because I suspect it will be more trouble than it's worth from a support perspective and people who just go installing pref files without knowing what they do, ahem (to others reading), but I'm glad it's helpful to you.

  2. CK - I just found two (2), 8-core Mac Pros for $100 each from a local newspaper sale, and both work fine. While their Mac OS compatibility is on the chopping block because of corporate greed, turns out they both run Linux and Windows 10 like a boss (made two of them into spankin' Steam Boxes for gaming).
    At this stage nobody is clinging to their PPC Mac because they can't afford newer or faster. Nobody is going to be disappointed if you finally call all of this, favor of your new PowerBox (and those folks in that camp REALLY NEED your help). My old mac will remain on my desktop forever because of the spectacular productivity apps, for writing, graphics and the like, but more and more, that 2nd monitor is tied to my Win10 box for browsing. People still running OS9 via Classilla, using TFF on a G3 really only seeing it work at all. When a Raspberry Pie is $20-$30, Even people in the 3rd world, have mostly moved on. Sometimes its just time.

    1. We'll just have to see. If I decide to hang it up, though, there will be a transition period.

  3. [ChrisT.]
    I have a similar strategy when the times comes that TFF & LWK together aren't viable anymore (right now I get by just fine, and I'm still PPC-only in my house and hope to remain that way for as long as possible): I will keep my PPC Macs with all the great productivity applications I collected over the years, and place a recent iPad on the same desk for web browsing. I use both macOS (Mojave) and Windows 10 at work and have decided not to use them at home, and neither will I use Linux. For me, the time of desktop OS's is over.

    No useful (to me) productivity apps; Scribus is no viable alternative to InDesign, and Gimp is no alternative at all for Photoshop. LibreOffice would be o.k., recent Firefox is available, but that's not enough for my needs.

    Win 10
    Is a lot better than its predecessors, and has the great plus that it can run older non-subscription productivity software like Acrobat Pro X, Adobe CS 1 to CS 4 etc., and at the same time runs the latest and greatest software if necessary. This is the only OS right now that would be generally useful to me if it weren't for the frequent updates that are forced on the users (even though they're necessary) and keep breaking stuff. Also, the UI is still a disaster, and you need the Enterprise edition to gain enough control over that to make it bearable.

    Since Mac OS X 10.7 Apple has been removing useful features and has dumbed down and locked down the system in a way I don't like at all. Modern macOS is still usable with Firefox/Waterfox and recent versions of productivity applications. But there is no downward compatibility whatsoever, all 32 bit apps are dead now. Macintosh hardware quality seems to be lacking, very hard or impossible to upgrade or repair modern Macs. It's easier to just use an iPad; unlike macOS, the iPadOS is being developed in the right direction.

    1. Mojave is the end of the road for macOS with me because of the 32-bit apocalypse.

      However, on Linux, I find Krita takes care of about 3/4ths of what I need Photoshop for. The interface is also more like Photoshop than the GIMP. On the other hand, for video and music apps, I still like Final Cut HD (the old version, not the new abomination) and Garage Band, so the G5 isn't doing nothing these days.

    2. I'm still relying on TFF for my mum's Mini G4 (my iMac G5's power supply won't allow it to boot anymore and I don't need it enough to spend time and money fixing it).
      I don't agree with artphotodude writing "Nobody is going to be disappointed, etc." and it's not a matter of "can't afford newer or faster", but in this particular case my mother is perfectly happy with her computer: at 87 years, she absolutely prefers staying with the whole thing as it is — I've considered switching to Linux, but there doesn't seem to be enough performance improvements to balance the learning of a new OS, etc. even if she's now using quite exclusively TFF and
      So when TFF is not being updated any more, she'll keep on using it that way until Internet doesn't change too much, and if the computer dies, I'll probably buy her something similar, minimizing the differences with what she's used to.

    3. I don't think your mother is the only one in that boat, so like I said above, there would be a support transition plan. It's mostly the build time in a compressed development cycle that's the major concern, to be honest.

    4. @ClassicHasClass I believe you mentioned once that it takes a little over 24 hours to do the builds for TenFourFox. Being as you can't shrink the build time any, why don't you just do more SPR's? There is no written rule that you have do a new feature and release a FPR whenever Mozilla release another version of Firefox. Like what you did with FPR16 and FPR16 SPR1. You can do a solid FPR then a series of SPR's that are just security fixes and the usual updates to the certs, pins, TLDs, miners, and blacklist. Then keep working on the few features you have left until one of those is ready to do a new FPR with.

  4. Thank you for restoring this, and thank you for including the general override in the TenFourFox preferences tab, with the correct useragent strings already included.

    When I tried it, I found that reports the general override value if one is set, and not the site specific one. (It reports the site specific value if there is no general override set.) Both and report the site specific value whether the general override is set or not.

    In bug []

    _Remove UserAgentOverrides.jsm _

    They mention using nsIDocshell.customUserAgent instead. I have no idea if this is something that can be set in about:config (in the current '70-something' Firefox), or if it is in any way compatible with the ESR45 era code. So this is not a request for any changes to TFF, just information.

    (but wait, there's more!)

    Somewhat related to "fingerprinting" issues, apparently, there is some local storage data kept under each Firefox profile (in the profile folder, in storage/default subfolders) that isn't cleared when history is cleared in preferences.

    Opening up the Storage Inspector under Tools/Web Developer, it simply says "No data present for selected host", so it can't be cleared from there.

    Entering 'localStorage.clear();' in the Browser Console simply brings the response "Component is not available" and nothing is cleared that way either.

    I have tried these methods under Safe Mode, with the same results.

    In bug []

    _ Implement clearing of LocalStorage in browsingData API _

    It looks like they patched this bug in Firefox 57 (and back to ESR52, maybe?).

    Can this (should this) be done for TenFourFox?

    1. 45ESR and TenFourFox don't have nsIDocShell.customUserAgent (this is part of the internal interface definition, not an about:config setting) and it wouldn't add any additional functionality to implement it IMHO since it's more like the general override setting, just on a specific docshell.

      Nothing personal, but I'm probably not going to do much further work on the site-specific overrides feature; it wasn't something I wanted to support in any case because I still believe it's likely to be confusing to users who don't know how to set it up, and I've got anecdotal reports saying that it *does* work as advertised, so I don't know what they're doing differently than you are.

      However, M1355576 does look feasible on a cursory glance. I need to verify that it doesn't require any later APIs but I agree that it would be a helpful feature to improve privacy, so I'll consider it for FPR18.

    2. It simply works exactly as intended - I can read MacRumors on the IE8 UA, browse to Youtube, it instantly picks up the Nokia UA and passes 3gp through to MPlayer and happily plays along under 20%CPU on my 1.33Ghz Powerbook. Excellent addition to TFF.


Due to an increased frequency of spam, comments are now subject to moderation.