Monday, October 8, 2018

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.

14 comments:

  1. It is AMAZING how well it all still works. Was on the New (crappy) Gmail on Linux AMD64 that is a bit heavy to say the least, and TFF still opened it right up. Bravo for your continued efforts. I wonder if it might be possible at some point, when this all gets impossible to run natively, to piggy-back browser support off of a microPC through screen-sharing or some such??

    ReplyDelete
    Replies
    1. I think it's pretty viable. Something like a ComputeStick or something would work if you want something small, or stick a Talos or a Blackbird in the closet with VNC.

      Delete
    2. I hate to admit it my friend, but outside of automotive, I suspect that the future belongs to ARM.

      Delete
    3. P.S. Have you been watching this guy? VERY good analysis of Apple's march to the Dark Side. https://www.youtube.com/watch?v=o2_SZ4tfLns

      Delete
  2. [ChrisTrusch]I suspect uBlock Origin v1.13.8. doesn't load correctly in FPR10 with security.data_uri.unique_opaque_origin enabled. Its icon is gone from the URL bar in FPR10, likewise gone from "customize" if I place it there in FPR9 beforehand. Also some of its buttons in Add-ons>uBlock Origin>Preferences (like 'show dashboard') are blank. Other add-ons seem to work normally.

    ReplyDelete
    Replies
    1. Does toggling the setting make a difference?

      I'm not sure I can do anything about this, however. Maybe something to see if the data: URI is generated by a chrome URL or addon, but that could be expensive to check.

      Delete
    2. Yes, if I toggle it to false everything is back to normal.

      Delete
    3. Pretending to be FF60 I was indeed able to install the latest version 1.17.0 of uBlock Origin, but, not unexpectedly, it doesn't work right. If it blocks anything at all, it doesn't count it (only displays '?'), and neither the logger nor the dashboard work. The button did return, though :-) Nevertheless had to revert to 1.13.8. But I guess the developer fixed the missing button in an update after FF 52 introduced security.data_uri.unique_opaque_origin. That's an unfortunate situation now.

      Delete
    4. Well, it's too late to issue a new release for this, so we'll have to see what we can do for FPR11. For FPR10 release I'll toggle it back to false. However, we really need this feature in the browser, so even if I can't find a workaround for add-ons it's got to be enabled sooner or later.

      Delete
  3. The most current version of uBlock that works with TenFourFox is https://github.com/gorhill/uBlock/releases/download/firefox-legacy-1.16.4.4/uBlock0.firefox-legacy.xpi from July 18th. Unfortunately, it has the same problem with security.data_uri.unique_opaque_origin as previous releases.


    And according to this statement from their wiki: https://github.com/gorhill/uBlock/wiki/Firefox-WebExtensions

    "uBO/webext has limited access to behind-the-scene network requests, unlike uBO/legacy which had full access to all behind-the-scene network requests. For example, you won't be able to see (and block) network requests made by other extensions. Related: "Support moz-extension: urls in MatchPattern"."

    So it seems that the current version might not have all the functionality of the one we're used to.


    However, the bug referenced in that wiki entry [https://bugzilla.mozilla.org/show_bug.cgi?id=1271354] describes some attempts by mozilla developers to work around the issue. Though it deals specifically with WebExtensions, could any of the proposed workarounds be of use for TenFourFox extensions that need to bypass the data: URIs unique origins problem we're encountering here?

    ReplyDelete
    Replies
    1. Not that bug specifically, because it's very WX specific, but I have an idea on how to do this. But it will need more testing time than I have available for FPR10.

      Delete
  4. Cameron,
    I'm just asking to know, but what's your general opinion of using handwritten assembly-optimized codepaths for acceleration? To precise, my question is *POWER(PC) ISA*-exclusive. I know IBM generally discourages doing so, even more when it involves vector instructions, but that and time cost factors aside, what's your viewpoint?

    ReplyDelete
    Replies
    1. My position is C compilers can't know everything, and particularly in register-rich architectures like PPC and MIPS they may not always make the best decisions. However, they generally make pretty good decisions, and they can do some optimizations that are tedious or difficult to do by hand. That's why I went with AltiVec intrinsics instead of handwritten assembly when I did the VMX SIMD work for VP9. But there's some handtuned assembly in the browser too.

      Delete
  5. I have visited YouTube.com/html5 and it still lists WebM VP8 as supported. Granted, it's the same old 360p file that some videos do not create right away, but it's still there. Are you sure that it's deprecated, or is it just a less-prioritized file for YouTube?

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.