Saturday, October 17, 2020

TenFourFox FPR28 available

TenFourFox Feature Parity Release 28 final is now available for testing (downloads, hashes, release notes). Since there are a couple more user-facing features landing hopefully for FPR29 out of some great work by OlgaTPark, we've temporarily held Raphaël's Enable JavaScript menu option since these will both require new locale strings and I'd rather not release two language pack sets back to back. Both features will instead debut officially in FPR29 with new langpacks side-by-side, along with some targeted Gecko fixes which should improve site compatibility as well.

In the meantime, all the other improvements and upgrades planned for FPR28 have stuck, and this final release adds updated timezone data as well as all outstanding security updates. Assuming no issues, it will go live as usual on or around Monday, October 19 Pacific time.

Sunday, October 4, 2020

TenFourFox FPR28b1 available (and a sordid tale of more Google screwery)

TenFourFox Feature Parity Release 28 beta 1 is now available (downloads, hashes, release notes). The two most noticeable changes in this release are the triumphant return of the user-exposed "Enable JavaScript" toggle (now moved to the Tools menu), as submitted by Raphaël, and further improvements to Reader View that make it current with Firefox 82. Because the new toggle menu item requires a new locale string that can't be built from existing ones, a langpack update will also be shipped parallel with this version.

Under the hood there are a couple layout fixes for text wrapping and upgrades to NSS, the browser's security and cryptography library. Of particular interest in that last is the change to Bernstein and Yang's fast constant-time greatest common divisor algorithm. Don't ask me the fine details of the math here, but switching to their variant of Fermat's little theorem over constant-time versions of Euclid's algorithm is not only faster, but particularly faster on weaker machines. And of course all our machines are considered weak by modern standards, so it's nice to see an upgrade that disproportionately benefits the low-end for a change. The usual security updates also apply. Unfortunately, although I was able to better narrow down what code at LinkedIn makes the browser crash, I am unable to minimize the crash to a working reproducible shell test case so far, so JavaScript on LinkedIn remains blocked at the browser level (issue 621) though you can turn it back on if you really have to.

Finally, there's one other minor change which ordinarily would not be worth calling out except for the story behind it. As first reported 17 (!) years ago, if a Content-Disposition header does not put the filename in quote marks, Firefox will split on whitespace, and if there are any spaces then the filename will be truncated. This is not a bug because RFC 2231 is clear on the requirements, but Internet Explorer and others took an excessively relaxed view of the spec and dupes of the report occurred repeatedly over the years. That brings us to bug 1440677, yet another dupe, where it was made clear that even if you want to relax the spec there still needs to be some consistency about what to relax it to. Google was consulted, and decided that "we'd prefer not to change behavior there, just out of a general desire not to break sites" while adding "I agree the spec unambiguously disallows unquoted spaces." (This from the company that decided FTP must die, even though that also certainly breaks sites.)

You can read that as Google saying, we know our behaviour is wrong, we're not interested in hashing out an independent standard because no one's complaining to us, and (effectively) Chrome's behaviour therefore determines how all other browsers should operate. So Mozilla gave up, and since one thing people do use their Power Macs for is downloading files, now we do as Chrome does too. After reading this whole exchange and others like it, I'm left with this thought question: why haven't we trust-busted Google yet? When, exactly, are they "too big" and need to be broken up? It's not money they're gouging us on: it's the hegemony of a Google-centric view of the Web where everything must be and benefit Google's way with no incentive nor even really interest to work with anybody else on a common playing field. Surely that's anticompetitive on some actionable level.

FPR28 goes final on or around October 20.

Saturday, September 19, 2020

TenFourFox FPR27 available

TenFourFox Feature Parity Release 27 final is now available for testing (downloads, hashes, release notes). Unfortunately, I have thus far been unable to solve issue 621 regarding the crashes on LinkedIn, so to avoid drive-by crashes, scripts are now globally disabled on LinkedIn until I can (no loss since it doesn't work anyway). If you need them on for some reason, create a pref tenfourfox.troublesome-js.allow and set it to true. I will keep working on this for FPR28 to see if I can at least come up with a better wallpaper, though keep in mind that even if I repair the crash it may still not actually work anyway. There are otherwise no new changes since the beta except for outstanding security updates, and it will go live Monday evening Pacific assuming no new issues.

For our struggling Intel friends, if you are using Firefox on 10.9 through 10.11 Firefox ESR 78 is officially your last port of call, and support for these versions of the operating system will end by July 2021 when support for 78ESR does. The Intel version of TenFourFox may run on these machines, though it will be rather less advanced, and of course there is no official support for any Intel build of TenFourFox.

Google, nobody asked to make the Blogger interface permanent

As a followup to my previous rant on the obnoxious new Blogger "upgrade," I will grudgingly admit Blogger has done some listening. You can now embed images and links similarly to the way you used to, which restores some missing features and erases at least a part of my prior objections. But not the major one, because usability is still a rotting elephant's placenta. I remain an inveterate user of the HTML blog view and yet the HTML editor still thinks it knows better than you how to format your code and what tags you should use, you can't turn it off and you can't make it faster. And I remain unclear what the point of all this was because there is little improvement in functionality except mobile previewing.

Naturally, Google has removed the "return to legacy Blogger" button, but you can still get around that at least for the time being. On your main Blogger posts screen you will note a long multidigit number in the URL (perhaps that's why they're trying to hide URLs in Chrome). That's your blog ID. Copy that number and paste it in where the XXX is in this URL template (all one line):

Bookmark it and you're welcome. I look forward to some clever person making a Firefox extension to do this very thing very soon, and if you make one post it in the comments.

Friday, September 11, 2020

TenFourFox FPR27b1 available (now with sticky Reader View)

TenFourFox Feature Parity Release 27 beta 1 is now available (downloads, hashes, release notes).

The big user-facing update for FPR27 is a first pass at "sticky" Reader View. I've been paying attention more to improving TenFourFox's implementation of Reader View because, especially for low-end Power Macs (and there's an argument to be made that all Power Macs are, by modern standards, low end), rendering articles in Reader View strips out extraneous elements, trackers, ads, social media, comments, etc., making them substantially lighter and faster than "full fat." Also, because the layout is simplified, this means less chance for exposing or choking on layout or JavaScript features TenFourFox currently doesn't support. However, in regular Firefox and FPR26, you have to go to a page and wait for some portion of it to render before you enter Reader View, which is inconvenient, and worse still if you click any link in a Reader-rendered article you exit Reader View and have to manually repeat the process. This can waste a non-trivial amount of processing time.

So when I say Reader View is now "sticky," that means links you click in an article in reader mode are also rendered in reader mode, and so on, until you explicitly exit it (then things go back to default). This loads pages much faster, in some cases nearly instantaneously. In addition, to make it easier to enter reader mode in fewer steps (and on slower systems, less time waiting for the reader icon in the address bar to be clickable), you can now right click on links and automatically pop the link into Reader View in a new tab ("Open Link in New Tab, Enter Reader View").

As always this is configurable, though "sticky" mode will be the default unless a serious bug is identified: if you set tenfourfox.reader.sticky to false, the old behaviour is restored. Also, since you may be interacting differently with new tabs you open in Reader View, it uses a separate option than Preferences' "When I open a link in a new tab, switch to it immediately." Immediately switching to the newly opened Reader View tab is the default, but you can make such tabs always open in the background by setting tenfourfox.reader.sticky.tabs.loadInBackground to false also.

Do keep in mind that not every page is suitable for Reader View, even though allowing you to try to render almost any page (except for a few domains on an internal blacklist) has been the default for several versions. The good news is it won't take very long to find out, and TenFourFox's internal version of Readability is current with mainline Firefox's, so many more pages render usefully. I intend to continue further work with this because I think it really is the best way to get around our machines' unfortunate limitations and once you get spoiled by the speed it's hard to read blogs and news sites any other way. (I use it heavily on my Pixel 3 running Firefox for Android, too.)

Additionally, this version completes the under-the-hood changes to get updates from Firefox 78ESR now that 68ESR is discontinued, including new certificate and EV roots as well as security patches. Part of the security updates involved pulling a couple of our internal libraries up to current versions, yielding both better security and performance improvements, and I will probably do a couple more as part of FPR28. Accordingly, you can now select Firefox 78ESR as a user-agent string from the TenFourFox preference pane if needed as well (though the usual advice to choose as old a user-agent string as you can get away with still applies). OlgaTPark also discovered what we were missing to fix enhanced tracking protection, so if you use that feature, it should stop spuriously blocking various innocent images and stylesheets.

What is not in this release is a fix for issue 621 where logging into LinkedIn crashes due to a JavaScript bug. I don't have a proper understanding of this crash, and a couple speculative ideas didn't pan out, but it is not PowerPC-specific or associated with the JavaScript JIT compiler as it occurs in Intel builds as well. (If any Mozillian JS deities have a good guess why an object might get created with the wrong number of slots, feel free to commment here or on Github.) Since it won't work anyway I may decide to temporarily blacklist LinkedIn to avoid drive-by crashes if I can't sort this out before final release, which will be on or around September 21.

Tuesday, September 1, 2020

I'm trying really hard to like the new Android Firefox Daylight. Really, I am.

I've used Firefox for Android nearly since it was first made available (I still have an old version on my Android 2.3 Nexus One, which compared with my Pixel 3 now seems almost ridiculously small). I think it's essential to having a true choice of browsers on Android as opposed to "Chrome all the things" and I've used it just about exclusively on all my Android devices since. So, when Firefox Daylight presented itself, I upgraded, and I'm pained to say I've been struggling with it for the better part of a week. Yes, this is going to be another one of those "omg why didn't I wait" posts, but I've tried to be somewhat specific about what's giving me heartburn with the new version because it's not uniformly bad and a lot of things are rather good, but it's still got a lot of rough edges and I don't want Daylight to be another stick Mozilla gives to people to let them beat them with.

So, here's the Good:

Firefox Daylight is a lot faster than the old Firefox for Android. Being based on Firefox 79, Daylight also has noticeably better support for newer web features. Top Sites are more screen-sparing. Dark mode is awesome. I like the feature where having private tabs becomes a notification: tap it and instantly all your naughty pages private browsing goes poof (and it's a good reminder they're open), or, if this doesn't appeal to you, it's a regular notification and you can just turn it off. Collections sound like a neat idea and I'll probably start using them if things get a little unwieldy. I'm not a bar-on-the-bottom kind of guy myself, but I can see why people would like that and choice is always good.

All this is a win. Unfortunately, here's the Bad I'm running into so far:

This has been reported lots of places, but the vast majority of the extensions that used to work with the old Firefox suddenly disappeared. For me, the big loss was Cookie Quick Manager, which was a great mobile-friendly way to manage cookies. Now I can't. Hope I don't screw up trying to get around those paywalls sites storing data about me. At least I still have uBlock Origin but I don't have much else.

Firefox Reader doesn't universally appear on pages it used to. Sometimes reloading the page works, sometimes it doesn't. This is a big problem for mobile. Worse, the old hack of prepending an about:reader?url= doesn't seem to work anymore.

Pages that open new windows or tabs sometimes show content and sometimes don't. This actually affects some of my sites personally, so I filed a bug on it. Naturally, it works fine in desktop Firefox and Chrome, and of course the old Android Firefox.

Oh, and what happened to the Downloads list? (This is being fixed.)

Now, some pesky Nits. These are first world problems, I'll grant, but my muscle memory was used to them and getting people onto a new version of the browser shouldn't upset so many of these habits:

When I tapped on the URL to go to a new site, I used to see all my top sites, so I could just switch to them with a touch. Now there's just a whole lot of empty space (or maybe it offers to paste in a URL left over in the clipboard). I have to open a new tab, or partially type the URL, to get to a top site or bookmark. This might be getting fixed, too, but the description of exactly what's getting fixed is a little ambiguous. Related to this, if you enable search suggestions then they dominate the list of suggestions even if it's obvious you're typing part of a domain name you usually visit. In the old browser these were grouped, so it was easy to avoid them if you weren't actually searching.

I often open articles in private browsing mode, and then tap the back button to go to the regular tab I spawned it from. This doesn't work anymore; I have to either switch tab "stacks" or swipe away the private tab.

Anyway, that's enough whining.

I don't really want to have to go back to the old Firefox for Android. I think the new version has a lot to recommend it, and plus I really despise reading bug reports in TenFourFox where the filer drops a bug bomb on my head and then goes back to the previous version. Seriously, I hate that: it screams "I don't care, wake me when you fix it" (whether or not it's really my bug) and says they don't have enough respect even to test a fix, let alone write one.

So I'm sticking with Firefox Daylight, warts and all. But, for all its improvements, Daylight needs work and definitely not at a time when Mozilla has fewer resources to devote to it. I've got fewer resources too: still trying to work on TenFourFox and keep Firefox working right on OpenPOWER, and now I may have to start doing PRs on the Android browser if I want that fixed also. It just feels like everything's a struggle these days and this upgrade really shouldn't have been.

Sunday, August 23, 2020

TenFourFox FPR26 available

TenFourFox Feature Parity Release 26 final is now (finally) available for testing (downloads, hashes, release notes). The delay is due to the severe heat wave and rolling blackouts we had here in overly sunny Southern California; besides the fact that Quad G5s have never been considered particularly power-thrifty, I had the A/C reduced to save electricity further and running the G5 and the Talos II simultaneously would have made the rear office absolutely miserable. There are no additional changes other than outstanding security updates, though since we will be switching to ESR78 for FPR27 anyway, I pulled a few lower-priority security and stability fixes from ESR78 in advance that didn't make it to ESR68. Assuming all goes well, it will go live tomorrow (Monday) afternoon/evening Pacific time.

For FPR27 we will be switching over the EV and TLS roots that we usually do for an ESR switch, and I would like to make a first pass at "sticky Reader mode" as well. More soon.