Partial work on native date pickers (with eventually time pickers) and support for idle callbacks (allowing better performance and scheduling of JavaScript tasks) is in FPR6, but they're not finished yet and therefore not enabled. The native date-time pickers use the standard NSDatePicker control instead of the XUL-based one in current versions of Firefox. Since we don't have to deal with a Windows or GTK version, we can just use the operating system controls built into Mac OS X and eliminate a lot of date management code by simply relying on the OS implementation; I have a prototype control working but haven't hooked it up to the input field yet (for simplicity, it will act as a OS modal window). Idle callbacks and support for requestIdleCallback exist in the WebIDL but don't connect to anything and there is only a skeleton implementation which does not yet function. The expected timeframe for these is somewhere around FPR7 or FPR8 and I will be working on them up until then; both of these are features I expect to see more use of, and we should support.
Unfortunately, unless you already have TenFourFox, you won't be able to download it: the "TLS apocalypse" has come to Power Macs running OS X. No browser that was previously available for PPC OS X can download TenFourFox now that SourceForge is mandating minimum TLSv1.1 support: Classilla, Safari 4, Safari 5, Camino and Firefox 3.6 all only support TLSv1.0. For that matter, TenFourFox didn't support TLSv1.1 or TLSv1.2 until version 31, when both were enabled (Mozilla added support in Firefox 27), and Safari didn't add support until version 7. The only other browser that supports TLSv1.1 or better on PPC OS X is Leopard WebKit when you also install the updated Security framework, and of course WebKit shells linked against those components, but it doesn't run on Tiger and it is also hosted on SourceForge.
SourceForge, however, is just following along with the general trend of removing TLSv1.0 support (SSLv2 and SSLv3 support have of course long since been deprecated on just about every major site). On February 22 -- tomorrow -- Github will end support for anything prior to TLSv1.2 and certain cryptographic algorithms. (If you are using a Power Mac to develop with a Github project, you'll need to upgrade your git and dependent components. I'm looking at providing those pieces as a way of facilitating development.) As the number of browsers limited to TLSv1.0 (and eventually v1.1) diminishes on the Web, more and more sites will remove support and be inaccessible to Power Macs with the default browser. Eventually this will impact things like the QuickTime Enabler which relies on the OS to download movie data, which someday no longer can.
I think it's a critical base feature that a Power Mac be able to bootstrap itself and download TenFourFox without having to use another computer. There is no way I can host several hundred megabytes on Floodgap itself, let alone deal with thousands of weekly downloads, but maybe we can just host a tool to handle the download instead. If you looked in that SourceForge directory already, you saw a new file: the TenFourFox Downloader. Grab it, copy it to one of your computers and see if it can fetch FPR5. It should be able to because it has all the pieces necessary to do so, including updated encryption and certificates, and using it should be self-explanatory. Assuming people report no problems, the Downloader will go live in a week or so and be offered from the main TenFourFox page to users on unencrypted HTTP who are using any non-WebKit browser other than TenFourFox, as well as systems without Leopard WebKit (TenFourFox and Leopard WebKit users will get regular HTTPS links as the site offers currently). While you could use the Downloader to do your version updates, it's really intended just to help new users starting from scratch to get off the ground.
Meanwhile, I'm in the midst of converting Floodgap to HTTPS, and https://gopher.floodgap.com/ is already live (and gets an "A" grade from Qualys SSL Test). However, even though the HTTPS/TLS version of Floodgap will support the latest security practices, there will always be an unencrypted version of Floodgap since I serve lots of old systems that don't even speak SSL. While I think the resurgence of the Gopher protocol means that Gopher is likely the best place for old computers to live, since it's a trivial protocol to implement, there's clients for even very limited systems like the Commodore 64(!), and lots of people in the retrocomputing hobby are rediscovering it, I'll still always offer alternatives to allow old systems to still be as useful as they can be and that means a perennial HTTP fallback just in case. That's what makes the Downloader a viable option.
Back to the invisible new feature. Google's Chrome group announced that they are now blocking "annoying" and "disruptive" ads in the browser. I think it should be applauded that Google is paying attention to this, but bear in mind Google is a media-advertising company first, and this move is a pre-emptive strike to make people not reach for adblockers as much. Instead, they'll rely on Google's adblocker, which, of course, will increasingly comply with the rules to not be as "annoying" and "disruptive" and still show you ads.
I don't care if ads are shown or not, personally. Sites need to make a buck to stay open, but if they're going to make that buck by being indiscriminate about what ad networks they use and inconsiderate of the burden they place on their viewers, then they should expect to be blocked. On our older, slower and more resource-limited systems, annoyances are not merely limited to obnoxious images and pop-over-under-arounders, but also larding sites up with additional processing from web scripts. This processing rarely benefits us directly, is usually used to spy on us, increases page load times and can bring the browser to its knees if multiple scripts are competing for the CPU because of JavaScript's "run to completion" semantics. But this isn't what Google wants to block, because these sorts of spy scripts are how they and their allied advertisers acquire their analytics.
Thus, may I present TenFourFox's basic adblock. Calling it adblock is sort of a misnomer because it's really a script block, but those scripts are usually loading ads or ad support libraries, so it achieves a similar effect. Basic adblock is implemented as a simple internal built-in blacklist. This blacklist is implemented at the "caps" level in the browser in C++, so it runs at native code speeds and can check very quickly (far, far faster than any adblock add-on, even Bluhell Firewall), and entries in the blacklist not only are marked as restricted and unable to execute code, but because they are marked as restricted, other components referencing them like adblocker-blockers also are unable to execute. The blacklist contains many common ad networks and "monetization" systems, as well as tag aggregators, user "engagement" and analytics systems, cryptocurrency miners and certain other types of arguable malware, all the major categories that make our lives online hell. The browser speeds up because there are many fewer scripts competing for resources, there are fewer pauses for garbage collection and there is less memory in use, and overall browsing performance improves.
The basic adblock is just that: basic. There is no claim that it is complete, nor will there ever be such a claim. Ads such as cooperative sponsorships that simply load images and aren't script-based, for example, will still appear (and, arguably, should; there's no easy way to distinguish such things programmatically). It's possible to add an imageblocker implemented in a similar fashion as well, but this would rapidly get into a situation where the overhead of scanning for these images exceeds the overhead of just displaying the images themselves (whereas the overhead of many of the scripts we block far exceeds any CPU time spent checking for them). For that matter, some scripts may just simply not be in the list yet. Similarly, the adblock is designed so that the functionality of a given site should remain basically the same whether it is enabled or not, which is why I haven't added entries for things like Disqus because they are part of the comments functionality on many sites, and Disqus may display some ads.
In addition, I had a firm rule while constructing the blacklist that if there is any ambiguity of what exactly is being blocked during the testing of an individual entry, or the entry causes a site to lose important features or fail to properly load, then that entry won't be added. Even when basic adblock is visibly exposed to users, it will never be enabled by default for exactly this reason. But the beauty of this scheme is that it's additive: if what's there (and it will be expanded) is not enough, you can use private browsing mode to block even more tracking scripts, or you can add an adblocker on top of basic adblock for even greater restrictions, depending on your taste and how much overhead you want to devote to that purpose.
To test it out, I first recommend either disabling or entirely removing any existing adblock or anti-tracker add-ons before you update so you can see basic adblock in its truest form. Update to FPR6b1, and in about:config set tenfourfox.adblock.enabled to true (you don't need to restart the browser). Open the MacOS Console (i.e., Console.app) and load a typical media website. Wow, look at what gets blocked! If you don't care for the running tally spamming your system log, set tenfourfox.adblock.logging.enabled to false. Logging will be disabled when the feature is released and finally exposed to users in the TenFourFox preference pane, but the log this option generates will be necessary if you need to report a site that basic adblock seems to disable or cause malfunctions on. I'm interested to hear your comments and how it interacts with other privacy add-ons, even though I myself am now surfing "naked" with only basic adblock so that I can try my own dogfood. I will be adding entries up until the FPR7 beta since the feature is not officially released yet, but once it becomes public (likely FPR7), new entries will only be added during the beta-test period to reduce regression risk from improperly or incompletely screened additions.
FPR6 final is scheduled for March 12.
