In this version, the hidden basic adblock feature introduced in FPR6 is now exposed in the TenFourFox preference pane:
It does not default to on, and won't ever do so, but it will reflect the state of what you set it to if you played around with it in FPR6. Logging, however, is not exposed in the UI. If you want that off (though it now defaults to off), you will still need to go into about:config and change tenfourfox.adblock.logging.enabled to false. The blocklist includes several more cryptominers, adblockerblockers and tracking scripts, and there are a couple more I am currently investigating which will either make FPR7 final or FPR8.
The other big change is some retuning to garbage and cycle collection intervals which should reduce the browser's choppiness and make GC pauses less frequent, more productive and more deterministic. I did a number of stress tests to make sure this would not bloat the browser or make it run out of memory, and I am fairly confident the parameters I settled on strike a good balance between performance and parsimoniousness. Along with these updates are some additional DOM and CSS features under the hood, additional HTTPS cipher support (fixing Amtrak in particular, among others) and some sundry performance boosts and microoptimizations. The user agent strings are also updated for Firefox 60 and current versions of iOS and Android.
To go along with this is an update to TenFourFoxBox which allows basic adblock to be enabled for foxboxes and updates the cloaked user agent string to Firefox 60. There is a new demo foxbox for 2048, just for fun, and updated Gmail and user guide foxboxes. TenFourFoxBox 1.1 will go live simultaneously with FPR7 final on or about May 9.
Meanwhile, the POWER9-based Talos II showed up in public; here's a nice picture of it at the OpenPOWER Summit running Unreal Engine with engineer Tim Pearson. I'm not in love with the case, but that's easily corrected. :) Word on the street is April for general availability. You'll hear about it here first.
No issues to report with FPR7b1 or TenFourFoxBox 1.1 after a couple days of use. Thanks, Cameron!
ReplyDeleteI noticed that often when TenFourFox grinds to a halt, Activity Monitor shows an extremely large portion of CPU time being devoted to the "System." I suspect these calls are the result of garbage collection.
ReplyDeleteMight it be practical to create a shim that might reduce the number of GC-generated calls to MacOS.
I think what you're seeing is issue 495. If you get crash dumps ending in that weird address, that's the same problem. If it's not, I need something reproducible.
ReplyDeleteYes, that's it. That stack address is "unpossible" and shouldn't happen normally; issue 495 was a regression caused by a faulty compatibility fix. If you notice other crashes faulting on that address or nearby, then it's the same issue.
ReplyDeleteThere's going to be an FPR7 beta 2 to pick up this fix and a couple others. I'm mulling over whether there should be an FPR6.2 in the meantime.