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.
> Why haven't we trust-busted Google yet?
ReplyDeleteBecause trust busting is a political act. Look at who the President of the United States is and look at what is going on in Europe; that's your answer for why there is no oversight.
It would be a good thing if there was an investigation into market practices as it does worry me that one browser engine has swallowed the whole Internet. It was a little different when both Apple and Google shared responsibility for Webkit/KHTML; but now days Google is dominant, Apple seems disinterested, and Microsoft is too much of a bit player to make a difference.
Would just like to say a big thank you for your continuing dedication in this - and along with TenFourFoxBox, it's a lifeline to my PPC Macs.
ReplyDeleteThe kind word is appreciated. :)
Delete