TenFourFox FPR10b1 available

TenFourFox Feature Parity 10 beta 1 is now available (downloads, hashes, release notes). This version is mostly about expanded functionality, adding several new DOM and JavaScript ES6 features, and security changes to match current versions of Firefox. Not everything I wanted to get done for this release got done, particularly on the JavaScript side (only one of the ES6 well-known symbols updates was finished in time), but with Firefox 63 due on the 22nd we'll need this period for sufficient beta testing, so here it is.

The security changes include giving document-level (i.e., docshell) data: URIs unique origins to reduce cross-site scripting attack surface (for more info, see this Mozilla blog post from Fx57). This middle ground should reduce issues with the older codebase and add-on compatibility problems, but it is possible some historical add-ons may be affected by this and some sites may behave differently. However, many sites now assume this protection, so it is important that we do the same. If you believe a site is behaving differently because of this, toggle the setting security.data_uri.unique_opaque_origin to false and restart the browser. If the behaviour changes, then this was the cause and you should report it in the comments. This covers most of the known exploits of the old Firefox behaviour and I'll be looking at possibly locking this down further in future releases.

The other notable security change is support for noopener, but using the soon-to-be-current implementation in Firefox 63. This feature prevents new windows (that were presumably unwittingly) opened to a malicious page from that page then trying to manipulate the page that opened it, and many sites already support it.

This release also now prefs MSE (and VP9) to on by default, since YouTube seems to require it. We do have AltiVec acceleration for VP9 (compare with libvpx for Chromium on little-endian PowerPC), but VP9 is a heavier codec than VP8, and G4 and low-end G5 systems will not perform as well. You can still turn it off for sites that seem to do better with it disabled.

There are two known broken major sites: the Facebook display glitch (worse on 10.5 than 10.4, for reasons as yet unexplained), and Citibank does not load account information. Facebook can be worked around by disabling Ion JavaScript acceleration, but I don't advise this because of the profound performance impact and I suspect it's actually just fixing a symptom because backing out multiple changes in JavaScript didn't seem to make any difference. As usual, if you can stand Facebook Basic, it really works a lot better on low-power systems like ours. Unfortunately, Citibank has no such workaround; changing various settings or even user agents doesn't make any difference. Citibank does not work in versions prior to Fx51, so the needful could be any combination of features newly landed in the timeframe up to that point. This is a yuuuge range to review and very slow going. I don't have a fix yet for either of these problems, nor an ETA, and I'm not likely to until I better understand what's wrong. Debugging Facebook in particular is typically an exercise in forcible hair removal because of their multiple dependencies and heavy minification, and their developer account has never replied to my queries to get non-minified sources.

So, in the absence of a clear problem to repair, my plan for FPR11 is to try to get additional well-known symbols supported (which should be doable) and further expand our JavaScript ES6/ES7 support in general. Unfortunately for that last, I'm hitting the wall on two very intractable features because of their size which are starting to become important for continued compatibility. In general my preference is to implement new features in as compartmentalized a fashion as possible and preferably in a small number of commits that can be backed out without affecting too much else. These features, however, are enormous in scope and changes, and depend on many other smaller changes we either don't need, don't want or don't implement. They also tend to affect code outside of JavaScript such as the script loading environment and the runtime, which is problematic because we have very poor test coverage for those areas.

The first is modules (we do support classes, but not modules), introduced in Firefox 60. The metabug for this is incredibly intimidating and even the first "milestone 0" has a massive number of dependencies. The script loader changes could probably be implemented with some thought, but there is no way a single programmer working in his spare time can do the entire amount of work required and deal with all the potential regressions, especially when rebuilding JavaScript takes up to 20 minutes and rebuilding the browser takes several hours or more. The silver lining is that some sites may need refactoring to take advantage of modules, so wide adoption is not likely to occur in the near term until more frontend development tools start utilizing them.

The second, unfortunately, is already being used now: async functions, introduced in Firefox 52, and really co-routines by any other name. The work to support them in the parser is not trivial but I've mostly completed it, and some of that code is (silently) in FPR10. Unfortunately, the await keyword works in terms of ES6 Promises, which we definitely do not support (we only have support for DOM Promises, which are not really interchangeable at the code level), and which extend hooks into the browser event loop to enable them to run asynchronously. You can see the large number of needed changes and dependencies in that Github issue as well as the various changes and regressions that resulted. This problem is higher priority because the feature is tempting to developers and some sites already make use of them (you usually see an odd syntax error and stuff doesn't load in those situations); the code changes needed to convert a function to asynchronous operation are relatively minor while yielding (ahem) a potentially large benefit in terms of perceived speed and responsiveness. However, there is no good way to make this work without ES6 Promise, and the necessary parser changes may cause code to run that can never run correctly even if the browser accepts it.

I don't have good solutions for these looming problems but I'll try to continue making progress on what I know I can fix or implement and we'll examine what this means for feature parity as time progresses. Meanwhile, please try out the beta and post your comments, and expect FPR10 final later this month.